The Node.js Security Handbook

Improve the security of your Node.js app with the Node.js Security Handbook made for developers.

Categories

Get the PDF version

Code

  • Avoid using fs, child_process and vm modules with user data

    The fs module allows access to the file system. Using it with unsafe data can allow a malicious user to tamper with the content of your server. The child_process module is used to create new processes. Using it can allow a malicious user to run their own commands on your server. The vm module provides APIs for compiling and running code within V8 Virtual Machine contexts. If not used with a sandbox, a malicious user could run arbitrary code within your web application.

    Node.js fs module documentation: https://nodejs.org/api/fs.html

    Node.js child_process module documentation: https://nodejs.org/api/child_process.html

    Node.js vm module documentation: https://nodejs.org/api/vm.html

  • Don't implement your own crypto

    The problem with cryptography is that you don’t know you are wrong until you are hacked. So don’t do your own crypto. Use standards instead. For most crypto related operations, the ‘crypto’ core module can help you.

    Read more:

    https://nodejs.org/dist/latest-v8.x/docs/api/crypto.html

    https://en.wikipedia.org/wiki/Bcrypt

    http://crypto.stackexchange.com/questions/43272/why-is-writing-your-own-encryption-discouraged

    https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/

  • When using a templating engine, do not use unsafe methods

    When using a templating engine, you should know which syntax can introduce XSS vulnerabilities. For instance, Pug (formerly, Jade) escapes all inputs by default unless you use the ‘!’ symbol.

    Check Pug’s documentation: https://pugjs.org/language/code.html

    Mustache documentation: https://mustache.github.io/mustache.5.html

  • Enforce a secure code review checklist

    Security should always be kept in mind while coding. Enforce security reviews for pull requests.

    Learn more:

    OWASP Code Review Project

    Security Code Reviews

  • Go hack yourself

    Once in a while, the entire technical team should sit together and spend time targeting all parts of the application, looking for vulnerabilities. This is a great time to test for account isolation, token unicity, unauthenticated paths, etc. You will heavily rely on your browser’s web console, curl, and 3rd party tools such as Burp.

    Learn more:

    Burp

    Red Team: Pwning the Hearts and Minds one Ticket at a Time

  • Keep secrets away from code

    Never commit secrets in your code. They should be handled separately in order to prevent them accidentally being shared or exposed. This allows a clear separation between your environments (typically development, staging and production).

    Use a configuration file/en variable Use a configuration management module: https://www.npmjs.com/package/config

    Learn more:

    12 Factor App

  • Keep your dependencies up to date

    Third-party libraries can put your application at risk. Make sure you track your vulnerable packages and update them regularly.

    Tools:

    Sqreen

    Node Security

    Snyk

  • Perform data validation on everything you don't control

    All user data that get into your application should be validated and escaped to avoid various kinds of injections. Or use Sqreen to protect from attacks exploiting NoSQL or SQL vulnerabilities.

    Learn more about MongoDB injections: https://blog.sqreen.io/mongodb-will-not-prevent-nosql-injections-in-your-node-js-app/

    Use Joi to perform data validation: https://www.npmjs.com/package/joi

    Learn more about SQL injections: https://en.wikipedia.org/wiki/SQL_injection

    Learn more about code injections in Node.js: [https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1-_server_side_js_injection.html](https://ckarande.gitbooks.io/owasp-nodegoat-tutorial/content/tutorial/a1-_server_side_js_injection.html)

  • Use a prepublish/pre-commit script to protect yourself

    Before committing your code or publishing your package to a repository, you should ensure no sensitive data will be shipped. Using a pre-commit hook or a pre-publish script helps to prevent such leaks. You should particularly look for: Database credentials, API keys or configuration files.

    A few npm packages can help placing pre-commit hooks: https://www.npmjs.com/package/pre-commit Use publish-please package: https://www.npmjs.com/package/publish-please

    Add a pre-publish script in your package.json file: https://docs.npmjs.com/misc/scripts

  • Run it unprivileged

    If an attacker successfully attacks your application, having it running as a restricted-user will make it harder for the attacker to take over the host and/or to bounce to other services. Privileged users are root on Unix systems, and Administrator or System on Windows systems.

  • Run security linters on your code

    Static Application Security Testing (SAST) is an easy and fast way to find unsafe patterns in your code. You can enforce SAST security checks with a pre or post-commit hook, but be aware of the high number of false positives.

    Tools:

    ESlint with the security plugin

    Awesome Static Analysis

  • Integrate security scanners in your CI pipeline

    Integrate a Dynamic Application Security Testing (DAST) tool in your CI. But just like SAST, be aware of the high number of false positives. Install Sqreen in monitoring mode to cut through the noise.

    Tools:

    Arachni

    OWASP Zed

    Acunetix

  • Use a secure development life cycle

    The secure development lifecycle (SDL) is a process that helps tackle security issues at the beginning of a project. While rarely used as is, it provides useful insights at all stages of the project, from the specification to the release. It will allow you to enforce good practices at every step of the project life.

    Read more:

    OWASP Secure Software Development Lifecycle Project

    Microsoft Security Development Lifecycle

  • Ensure you are using security headers

    Modern browsers support a set of headers dedicated to blocking certain types of attacks. Make sure you have properly implemented all security headers. Don’t forget about the Content Security Policy

    Learn more:

    Helmet

    Check your headers and other security configs

    Check your headers and more

    HTTP Security Headers

Infrastructure

Protection

Monitoring

We’re publishing great new resources every week. Get them sent straight to your inbox.