Schwesi Design Blog Post

The popular JavaScript runtime Node.js has proven itself to be an amazing tool to build software with. At the time of this writing Node.js powers over 20 million websites, among them Amazon, AliExpress, Netflix, LinkedIn and Reddit just to name a few. For good reason, it excels at optimizing application performance, development costs, as well as developer experience. With growing popularity comes growing scrutiny from attackers. Therefore, it seems to be more important than ever to know about the most basic vulnerabilities, which typically occur during the development process and how to tackle them.

Linting for Vulnerabilities

Nowadays it is common to use tools, which ensure a standardized codebase, making it more readable and maintainable. The most popular tool in this domain is ESLint. There are plugins to extend ESLint to catch security-related issues, such as eslint-plugin-security. This will mostly help with DOM related security issues, like Cross Site Scripting or Arbitrary Redirects. In my opinion using such tools is a no brainer, as it allows you to catch security issues while they are being created.

Explicitly crashing Processes

This really shines a light on thoughtful error handling. If you do not handle errors your application will crash unexpectedly. This might give an attacker the opportunity to probe your application for circumstances that make it crash, which can be used in for example a DOS attack.

Secure Headers

Cross Site Scripting attacks allow an attacker to inject malicious scripts into an application. This is a very common attack, which if done correctly might open the entire application to further attacks. User input validation, as well as the helmet module help mitigate the risk tremendously.

Salt and Hash Passwords

No matter how many precautions you take, an application is never 100% secure. Hence, it is very important to prepare for your user data being stolen. Hashing and salting passwords will make them unusable even if they get into the wrong hands, because it is very hard to decrypt them. The go to plugin for this is bcrypt.

Limiting form submits

Leaving form submission frequency unchecked, brute force attacks are a major concern. As well as dDOS attacks by simply overwhelming the server with form submits, hence server requests. There are multiple ways to track the number of form submits from one source and limiting them. A starting point is to track IP addresses and the number of form submits and simply gradually increasing the time period between possible form submits. Google’s reCAPTCHA is a popular solution to discriminate between humans and machines (i.e. spam bots). For the data privacy concerned readers there are similar solutions from other providers, i.e. hCaptcha.

Evil Regular Expressions

Regular Expressions are amazing at describing search patterns or validating user input against a pattern. However, they might be very computing power intensive. Regex done wrong might lead to a single request blocking an entire event loop. This leaves an application vulnerable to Regular Expression DoS attacks. This can be prevented by avoiding Regular Expressions altogether or using tools like safe-regex.

Think about your Error Messages

Creating your own error handler often makes sense. However, it is utterly important to consider the risk of exposing sensitive application details such as server filepaths, third party modules in use, and other internal workings of the application to the client. This information might be found in stack trace. More details on how to hide the error details can be found here.

Prevent unsafe redirects

Redirects should always validate user input, otherwise an attacker may post specially-crafted links to a malicious website. On first look these links will look legitimate, since they contain the applications hostname.

Imported Security Vulnerabilities

With over half a million packages, Node’s Package Manager (NPM) is by far the largest package ecosystem in the world. Even if npm does everything in its power to secure the registry, it can still happen that modules have security vulnerabilities. As most applications can easily end up depending on hundreds if not thousands of modules, auditing each one of them before you start using them is not something you have the time to do. Luckily, the Node.js Security Project, as well as Snyk maintains security advisories


Next Post

Nuxt State Post Nuxt State
scroll to top