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.
https://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.
https://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
https://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.
https://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.
https://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.
https://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
https://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.
https://www.petecorey.com/blog/2015/04/03/black-box-meteor-triple-brace-xss/
https://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.
https://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.
https://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
https://www.petecorey.com/blog/2015/04/15/black-box-meteor-method-auditing/
https://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
https://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.