Stay in touch!
We're publishing great new resources every week.
Get them straigth to your inbox.
Improve the security of your Node.js app with the Node.js Security Handbook made for developers.
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
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, 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
Security should always be kept in mind while coding. Enforce security reviews for pull requests.
Learn more:
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:
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:
Third-party libraries can put your application at risk. Make sure you track your vulnerable packages and update them regularly.
Tools:
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.com/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)
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
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.
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:
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:
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:
An automated configuration management tool helps you ensure that your servers are updated and secured.
Chef: https://learn.chef.io/tutorials/
Ansible: http://docs.ansible.com/ansible/intro_getting_started.html
Salt: https://docs.saltstack.com/en/latest/topics/tutorials/walkthrough.html
Your data is likely to be your business’s most precious asset. Be sure not to lose it. Implement proper backups and check for backup integrity.
MongoDB Backup: https://docs.mongodb.com/manual/core/backups/
Postgresql: https://www.postgresql.org/docs/current/static/backup.html
Linux: http://www.tecmint.com/linux-system-backup-tools/
https://www.dataone.org/best-practices/ensure-integrity-and-accessibility-when-making-backups-data
Use free tools to scan your infrastructure regularly and make sure the SSL configurations are correct.
https://observatory.mozilla.org/
https://diogomonica.com/2015/12/29/from-double-f-to-double-a/
The best way to protect your services (database, file storage) is to not use passwords at all. Use the built-in Identity and Access Management (IAM) functions to securely control access to your resources.
http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances
SSL performance problems are a myth and you don’t have any good reasons not to use SSL on all your public services.
Learn more:
Infrastructure logs and application logs are your most precious allies for investigating a data breach. Make sure your logs are stored somewhere safe and central. Also make sure you whitelist- or blacklist-specific incoming data to avoid storing personally identifiable information (PII).
https://qbox.io/blog/welcome-to-the-elk-stack-elasticsearch-logstash-kibana
When you need to store cryptographic secrets (other than database password, TLS certificate, etc.) and perform encryption with them, you should use dedicated tools. This way the cryptographic secret never leaves the tool and you get auditing features.
Tools:
Be proactive and be alerted when authorizations or keys binary are changed in your production.
http://techblog.netflix.com/2017/03/netflix-security-monkey-on-google-cloud.html
Just like TLS certificates, DNS can expire. Make sure you monitor your DNS expiration automatically.
Your servers will be scanned in order to fingerprint your application and locate open services, misconfigurations, etc. You can setup tools to keep these scanners away from your servers.
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-14-04
Credential stuffing or brute force attacks are easy to setup. You should make sure your users are protected against account takeovers.
https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
You should be using TLS certificates. It can be a hassle to configure and monitor, but don’t forget to renew them!
Storing passwords (like database ones) can be done on a dedicated database with restricted access. An other solution is to store them encrypted in your Source Code Management (SCM) system. That way, you just need the master key to decrypt them.
Chef: https://github.com/chef/chef-vault
Puppet: https://puppet.com/blog/encrypt-your-data-using-hiera-eyaml
Salt: https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html
Ansible: http://docs.ansible.com/ansible/playbooks_vault.html
Server packages and libraries are often updated when security vulnerabilities are found. You should update them as soon as a security vulnerability is detected.
Use immutable infrastructures to avoid having to manage and update your servers.
https://martinfowler.com/bliki/ImmutableServer.html
https://hackernoon.com/configuration-management-is-an-antipattern-e677e34be64c#.n68b1i3eo
Use third-party services to store credit card information to avoid having to manage and protect them.
https://www.braintreepayments.com
https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf
https://medium.com/@folsen/accepting-payments-is-getting-harder-1b2f342e4ea#.897akko4q
Enforce 2FA on all the services used (whenever possible).
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
Comply to standards to ensure you follow industry best practices and answer your customer needs. But simple compliance will never protect your apps. Make sure you also take security seriously.
Learn more:
https://cloudsecurityalliance.org/
https://en.wikipedia.org/wiki/ISO/IEC_27001:2013
https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
A bug bounty program will allow external hackers to report vulnerabilities. Most of the bug bounties program allow you to offer rewards for bugs found. A lot of the reports won’t be valuable and you need security aware people inside your development teams to evaluate the bugs you receive. These programs are good additions to other security initiatives and can’t by no means be considered as enough.
Places to start:
Launching an Efficient and Cost-Effective Bug Bounty Program
This is a page on your corporate website describing how you plan to respond to external bug reports. You should advertise that you support responsible disclosure. Keep in mind that most of the reports that you receive aren’t relevant. Don’t freak out if you receive so called “critical disclosures”
Check out the Open Source Security Page
Use Docker (or Kubernetes), and ensure that they are patched and secure. Use tools to automatically update and scan your containers for security vulnerabilities.
https://www.docker.com/docker-security
https://docs.docker.com/docker-cloud/builds/image-scan/
https://jpetazzo.github.io/2015/05/27/docker-images-vulnerabilities/
https://www.slideshare.net/MichaelCherny/security-best-practices-for-kubernetes-deployment
DoS attacks are meant to break your application and make it unavailable to your customers. Use a specific service to protect your app against Distributed Denial Of Service attacks.
Tools:
A real-time protection tool like Sqreen allows you to orchestrate your app security easily. Sqreen will enable you to get full visibility on your security, prevent data breaches, protect your customers, and stop business logic attacks. Customize your application’s response to attacks (block attack, log stack trace etc.) and get notified when something important happens.
With cloud providers, it’s easy to start instances and forget about them. You will need to create and maintain a list of your assets (servers, network devices, services exposed etc…), and review it regularly to determine if you still need them, keep them up to date, and ensure that they benefit from your latest deployments.
Learn more:
http://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html
http://searchenterpriselinux.techtarget.com/tip/Creating-an-inventory-with-nmap-network-scanning
The most important attacks will come from attackers who have acquired larger attack surfaces. Those can be attackers with regular user accounts or users having gained access to privileged user accounts. Make sure you monitor your users to detect attackers early.
You will be attacked. Make sure you have a monitoring system in place that will detect security events targeting your application before it’s too late. Knowing when your application is starting to get massively scanned is key to stop more advanced attacks.
https://www.linode.com/docs/security/using-fail2ban-for-security#email-alerts
You’re likely to use third party products to manage your servers / payrolls / logs or even just social media. Just like you’re likely to be hacked, they can be too. Make sure you follow the news and react immediately after a breach.
We're publishing great new resources every week.
Get them straigth to your inbox.