Best practices for securing your Node.js apps

In January 2018, a ride-hailing service experienced a significant data breach, exposing the personal and financial information of 14 million users. This incident emphasized how even well-designed systems can face security challenges without proper safeguards.

Node.js is an open-source, cross-platform JavaScript runtime environment that executes JavaScript code outside a web browser. Due to its lightweight runtime, it is popular among beginners and is used by many big companies, such as Netflix and Uber.

While Node.js is secure, applications built with it can be vulnerable to attacks if proper security measures are not in place. With cyber threats becoming increasingly sophisticated, it’s crucial to implement strict security measures to protect your applications and safeguard your users’ sensitive data.

This blog will explore common attacks targeting Node.js applications and provide steps you can take before and during the development process to ensure your application’s security.

Understanding common security threats#

Before you can defend your Node.js application, it’s important to understand how attackers might try to exploit it. Here are some common security threats:

1. Cross-site scripting (XSS)#

XSS attacks happen when attackers inject malicious scripts into web pages that other users subsequently access. This can lead to data theft, session hijacking, and website defacement. XSS often exploits input forms that are not properly sanitized or encoded.

Suppose you have a comment section on your website where users can post comments. The server-side code takes the user’s input and renders it on the page without sanitization.

Consider this attack scenario where an attacker adds this comment:

When other users visit the comments page, the malicious script executes in their browsers, displaying an alert. In a more severe attack, the script could steal cookies or perform actions on behalf of the user.

How to prevent XSS attacks#

• Sanitize user input: To ensure security, rigorously sanitize and validate user inputs. Remove or escape potentially malicious code before processing the data, and enforce strict validation rules as early as possible when the input is first received.

• Encode data on the output: Always encode the data generated by a user before rendering it on web pages. For example, convert < to < and > to >.

Let’s examine an example of modifying the code above to prevent XSS attacks on the server and client sides.

In the code above, we can use third-party libraries to sanitize inputs or manually sanitize user inputs by escaping special characters to ensure safe rendering on the server side.

On the client side, instead of using document.write, which can execute scripts, we’ll use textContent to safely render user comments as plain text.

2. Cross-site request forgery (CSRF)#

CSRF attacks manipulate authenticated users into executing unintended actions within a web application. Attackers can craft malicious requests that can perform actions like changing account details or initiating transactions without the user’s consent. The user’s browser executes these requests. Hackers can send users links through chat or email, asking them to change email addresses or transfer funds.

Imagine a banking application where users can transfer funds by submitting a POST request to the /transfer route.

Consider this attack scenario where an attacker crafts a malicious website with the following code. When a browser encounters an <img> tag, an automated HTTP GET request is sent to the specified src URL to fetch the image. The style="display:none;" attribute ensures the malicious request remains hidden from the user so they won’t notice anything suspicious on the page.

When logged-in users visit the malicious site, their browser sends a request to the /transfer endpoint, initiating a fund transfer without their knowledge.

How to prevent CSRF attacks#

• CSRF tokens: Implement CSRF tokens in your forms and API requests. A CSRF token is a random value generated on the server and verified with each request.

• Set SameSite cookies: Configure cookies with the SameSite attribute to prevent them from being sent with cross-site requests.

• Validate HTTP headers: Check the Origin or Referer headers to ensure requests originate from your domain. Reject requests with missing or mismatched headers.

3. SQL injections#

SQL injection attacks happen when attackers insert malicious SQL statements into input fields, manipulating database queries to access or modify data without authorization.

Suppose you have a login form where users enter their username and password.

Consider this attack scenario where an attacker enters the following input:

• Username: admin' --

• Password: pass123

The final SQL query is as follows:

The -- is a SQL comment operator, so everything after it is ignored. The query effectively becomes:

This might allow the attacker to log in as the admin without knowing the password.

Let’s consider a more dangerous injection, where an attacker could attempt to dump the entire user table:

• Username: ' OR '1'='1' --

• Password: pass123

The final SQL query is as follows:

As we know, '1'='1' is always true. Thus, the query will return all users from the table.

How to prevent SQL injection attacks#

• Use parameterized statements: Parameterized statements ensure that user inputs are treated as data and not executable SQL code. They allow your database to distinguish between data and code, regardless of the input. For example, if a user enters 100 OR 1=1 as their userID, a parameterized statement will not interpret OR 1=1 as SQL logic. Instead, it will search for a userID that matches the string 100 OR 1=1.

• Apply input validations: Input validations add an extra layer of protection. When writing your validation logic, you can compare an input to a list of allowed options. Input validation protects you from XSS attacks, DoS, and other injection attacks.

• Use database accounts with the least privileges: Using database accounts with minimum required privileges protects your application from SQL injections. Don’t use admin-level rights database accounts in your Node.js app. Create different users with read-write and read-only permissions. Lastly, use SQL views to limit access to specific table columns or joins.

• Sanitize input: You need to ensure you get rid of suspicious-looking input. You can do that by checking that fields like email addresses match a regular expression, alphanumeric or numeric fields do not contain special characters, and strip any newline or white space characters.

4. Denial-of-service (DoS)#

DoS attacks aim to make a service unavailable by constantly creating traffic or sending resource-consuming requests, causing slowdowns or crashes. For instance, an attacker might send many requests to your server, exhausting its resources.

How to prevent DoS attacks#

• Rate limiting: Restrict the number of requests an IP address or user can make within a specified time frame. For example, allow 100 requests per minute per user.

• Caching using content delivery networks (CDNs): CDNs distribute traffic across multiple servers, absorbing excessive loads. They cache content to reduce the burden on the origin server.

5. Brute-force attacks#

Brute-force attacks involve automated attempts to guess passwords or encryption keys through exhaustive trial and error. They can crack encrypted passwords and PINs. For example, an attacker can use a script to repeatedly attempt to log in to user accounts by trying many password combinations.

How to prevent brute force attacks#

• Account lockout: Temporarily lock accounts after several failed login attempts (e.g., 5 attempts within 10 minutes). Increase the lockout duration with each failed attempt to slow down brute force attempts.

• Implement CAPTCHA: Use CAPTCHA challenges to ensure that humans, not automated bots, make login attempts.

• Multi-factor authentication (MFA): Use MFA where the application requires a second form of authentication, such as OTPs via email, SMS, an authenticator app, or biometric authentication like fingerprints or facial recognition. This adds a layer of security, even if passwords are compromised.

6. Dependency vulnerabilities#

Using third-party packages from npm, Node.js’s default package manager can introduce vulnerabilities, especially if the packages are outdated or malicious. Supply chain attacks exploit these dependencies to compromise applications.

Suppose you use a package that has a known vulnerability allowing remote code execution. An attacker can exploit this vulnerability to execute arbitrary code on your server.

How to prevent dependency vulnerabilities#

• Regularly update dependencies: Tools like npm outdated and npm audit allow you to identify outdated or vulnerable packages and fix security issues. Regularly update dependencies to ensure you have the latest patches for known security vulnerabilities.

• Use trusted sources: Only install packages from reputable sources and maintainers.

• Lock dependencies: Lock files (like package-lock.json or yarn.lock) to ensure consistent dependency versions across environments, minimizing the risk of inadvertently introducing vulnerable versions.

Securing HTTP headers#

HTTP headers enable the exchange of information between the server and client regarding the connection setup, the requested resource, and the resource provided in response. Ignoring HTTP headers can leak sensitive information.

Express apps, by default, include the X-Powered-By header. This header lets the browser know the server’s version and vendor used. Hackers can cross-reference this with publicly disclosed vulnerabilities, allowing your app to be targeted easily.

One solution is to use Helmet.js. It is a Node.js module that helps secure your app by setting various HTTP headers. Helmet helps hide the X-Powered-By header, thus preventing the disclosure of server information, and sets security headers such as Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, etc.

Implementing secure password storage#

Storing passwords securely is one of the most critical aspects of application security. If user passwords are compromised, it can lead to unauthorized access and data breaches. Storing passwords in plain text is a severe security risk. If your database is compromised, attackers immediately access all user accounts.

Password encryption allows you to convert your passwords into an unreadable message using an encryption key. The encryption key is a mathematical value you and the recipient know.

Hashing vs. encryption#

• Encryption transforms data into a different format using a key, and the original data can be retrieved using a decryption key. Encryption is reversible, which makes it unsuitable for password storage.

• Hashing converts data into a fixed-size string of characters, typically a digest that cannot be reversed to obtain the original data. Hashing is a one-way function, making it ideal for password storage.

Hashing is different from encryption because it doesn’t have a decryption key. Hashing should always include salt, a random value added to the password before hashing. Salting passwords adds uniqueness, making it much harder for attackers to use precomputed tables (rainbow tables) to crack the hashes.

Here’s how it works: Suppose the user’s password is Pa55word. When hashed using a secure algorithm like bcrypt, it might look like $2b$10$wqGJ3YQ0yRhv5Tc.s7.Y. When the user logs in, the entered password is hashed again with the same algorithm and compared to the stored hash. If the two hashes match, you are signed in.

Hashing passwords#

For Node.js, you can use the bcrypt package to hash and store passwords. When a user registers or changes their password, you should hash the password before storing it in the database.

In the code above, saltRounds in bcrypt refers to how bcrypt generates a random salt internally and determines the computational cost of the hashing process.

Verifying passwords#

When a user attempts to log in, you need to verify that the supplied password matches the stored hash.

Protect against race conditions#

Race conditions occur when multiple processes access a shared resource simultaneously, and one or more want to modify it. This results in an unexpected logical flow. In Node.js applications, race conditions can lead to unexpected behavior, data corruption, and critical security vulnerabilities. Attackers can exploit race conditions to:

• Bypass security checks: An attacker might gain unauthorized access if authentication or authorization steps are not properly synchronized.

• Manipulate data: Concurrent operations might allow attackers to interfere with data integrity, such as modifying financial transactions or sensitive information.

Consider an application that handles fund transfers between accounts. If two transfer requests are processed simultaneously, both might read the same initial balance before either has updated it. This could result in an overdraft, allowing users to transfer more money than is available.

How to prevent race conditions#

• Use database transactions. Transactions ensure a series of database operations are executed as atomic units. The entire transaction is rolled back if any operation fails, maintaining data integrity.

• Implement locks or mutexes: Locks prevent multiple processes from accessing a resource simultaneously, ensuring that only one operation can modify the resource.

• Properly handle asynchronous code: Ensure all asynchronous operations are awaited or properly chained to prevent code from executing out of order.

Conclusion#

Securing your Node.js application is an ongoing process that requires attention at every stage of development. By understanding common threats and implementing the best practices outlined above, you can significantly enhance the security of your applications.