Below you'll find a comprehensive Meteor security checklist that's intended to help you cover all the bases when it comes to securing your Meteor project. For a more in-depth guide to securing your application, be sure to read Secure Meteor!
Use Package Scan to check for Meteor packages with known vulnerabilities.
Your application code may be secure, but if you’re using a vulnerable Meteor package, your application is vulnerable.
https://github.com/east5th/package-scan
Use Snyk and/or NSP to check for Node.js packages with known vulnerabilities.
Node.js dependencies lay the foundation for your Meteor application. Make sure that your foundation is sound.
http://www.petecorey.com/blog/2016/06/20/node-vulnerability-scanners-in-a-13-world/
Thoroughly check all method, publication, and route arguments.
Using check to make assertions about the type and shape of user inputs can prevent entire families of NoSQL injection vulnerabilities. Never pass unchecked data into a query.
http://www.petecorey.com/blog/2016/03/21/nosql-injection-in-modern-web-applications/
https://github.com/East5th/check-checker
Use trusted fields (like this.userId) whenever possible.
Never use a user-provided field when a trusted alternative is available.
https://guide.meteor.com/security.html#user-id-client
http://www.petecorey.com/blog/2015/05/05/meteor-security-in-the-wild/
Verify that methods, publications, and server-side routes are making authentication and authorization checks.
Always verify that the current user has permission to do the thing they’re trying to do. Similarly, never assume that an unauthorized user can’t call a method or publication because it wasn’t publicly defined.
http://www.petecorey.com/blog/2016/02/01/sending-emails-through-hidden-methods/
Always be aware of where your code is running.
In a Javascript-everywhere ecosystem, we can sometimes forget whether a specific piece of code runs of the client or the server.
http://www.petecorey.com/blog/2015/09/21/never-forget-where-your-code-runs/
Test that MongoDB queries are behaving as expected in all circumstances.
Incorrectly written queries can lead to over-publishing and the leaking of data to the client.
http://www.petecorey.com/blog/2016/09/05/querying-non-existent-mongodb-fields/
Rate limit and unblock your methods and publications where appropriate.
Take basic precautions against attackers potentially carrying out Denial of Services attacks through excessive method calls or subscriptions.
https://guide.meteor.com/security.html#rate-limiting
Avoid allow & deny collection validators.
Allow and deny rules can be hard to reason about and even harder to implement correctly.
https://guide.meteor.com/security.html#allow-deny
http://www.petecorey.com/blog/2015/06/15/allow-and-deny-challenge-check-yourself/
Always whitelist the fields of documents returned by methods and subscriptions.
Whitelisting the fields returned by a query can prevent sensitive data being accidentally leaked to the client.
https://guide.meteor.com/security.html#fields
Use reactive data sources to securely invalidate cursors returned by publications.
Use reactive data sources like this.userId, or the reactive-publish package to continually ensure that a user is authorized to see the data being published.
https://guide.meteor.com/security.html#publications-user-id
https://github.com/peerlibrary/meteor-reactive-publish
Limit and audit the use of raw HTML injection.
Triple braces in Blaze, dangerouslySetInnerHTML in React, and jQuery’s html should be used sparingly. User-provided data being injected directly into the DOM must be thoroughly sanitized.
http://www.petecorey.com/blog/2015/04/03/black-box-meteor-triple-brace-xss/
http://www.petecorey.com/blog/2015/09/07/hijacking-meteor-accounts-with-xss/
Check for other instances of cross-site scripting vulnerabilities.
Third party packages and plugins can sometimes be vulnerable to cross-site scripting attacks. Make sure you’re sanitizing user-provided data before handing it off to any front-end library.
http://www.petecorey.com/blog/2016/03/14/stored-xss-and-unexpected-unsafe-eval/
Tighten up your content security policy.
Use the browser-policy Meteor package to add a Content Security Policy to your application. Fine tune the CSP to meet your application’s needs.
Always use TLS/SSL.
Use force-ssl or configure your load balancer/reverse proxy to always redirect clients to a secure connection.
https://guide.meteor.com/security.html#ssl
Consider rate limiting static asset and /websocket requests.
Upfront work can mitigate the pain of Denial of Service attacks in the future.
http://www.petecorey.com/blog/2016/05/16/the-missing-link-in-meteors-rate-limiter/
Ensure no sensitive business secrets are being bundled with the client Javascript application.
Malicious users can inspect the source code and extract your sensitive business secrets or processes.
https://guide.meteor.com/security.html#secret-code
http://www.petecorey.com/blog/2015/04/15/black-box-meteor-method-auditing/
http://www.petecorey.com/blog/2016/02/15/method-auditing-revisited/
Never keep API tokens or other secrets directly in your source code.
Secrets kept in code can mistakenly find their way to the client where they can be discovered and abused by malicious users.
https://guide.meteor.com/security.html#api-keys
http://www.petecorey.com/blog/2015/04/15/black-box-meteor-method-auditing/
Don’t expose secrets through the public field of Meteor.settings.
Secrets stored in public will be exposed to the client.