5 Node.js security code snippets every backend developer should know
Tags: applicationsecurity, codesecurity, javascript, node
Published: 2024-02-29 02:00:29

As backend developers, we are tasked with the crucial role of ensuring the security of our applications. Node.js is not exempt from this responsibility and its growing popularity makes it a lucrative target for hackers, making it imperative to follow best security practices when working with Node.js.


In this blog post, we will be exploring some essential Node.js security code snippets every backend developer should know in 2024. Node.js software vulnerabilities can be a significant threat to any application. They can lead to unauthorized access, data leaks, and in worst-case scenarios, a complete compromise of the system. For this reason, adhering to security best practices is not just a recommendation, but a requirement.


In the context of Node.js, this means ensuring that your code doesn't expose any loopholes that could be exploited. It means sanitizing user input to prevent injection attacks, properly treating passwords as sensitive data, and managing dependencies to prevent third-party vulnerabilities, among other practices.


We will review the following Node.js security concepts and their associated code snippets based on their effectiveness in preventing common security vulnerabilities and being very accessible to developers without requiring extra security expertise:


1. [Use the Node.js Permissions Model to restrict access to resources during runtime](#1)
2. [Implement input validation with a Fastify JSON schema](#2)
3. [Secure password hashing with Bcrypt](#3)
4. [Prevent SQL injection attacks with Knex.js](#4)
5. [Implement rate limiting with `fastify-rate-limit`](#5)


1. Use the Node.js Permissions Model to restrict access to resources during runtime
-----------------------------------------------------------------------------------


The Node.js Permissions Model can play a critical role in securing your applications. It is a key part of the core Node.js security model, ensuring that your applications are safe from attacks and malicious activities. Similar to the security promise that Deno brought about process-centric resource constraints, Node.js is now up to par (to an extent) with a similar permissions model.


Consider a scenario where a Node.js application needs to convert PDF files into PNG images. We could use the `pdf-image` npm package to accomplish this task. The `pdf-image` package uses child processes to carry out the conversion. To enable this, we need to use the `--allow-child-process` flag in the Node.js runtime (provided by the permissions model).


Below is a code snippet demonstrating this:



```
const { PDFImage } = require('pdf-image');
const path = require('path');

const pdfPath = path.resolve(__dirname, 'sample.pdf');
const pdfImage = new PDFImage(pdfPath, {
  convertOptions: {
    '-density': '300',
    '-quality': '80'
  },
  combinedImage: true
});
pdfImage.convertFile().then(() => {
  console.log('PDF converted to PNG successfully');
}).catch((err) => {
  console.error(`Failed to convert PDF to PNG: ${err}`);
});
```

In this snippet, we're creating a new instance of `PDFImage` with the path to our PDF file and some conversion options. We're then calling `convertFile()` to convert the PDF into a PNG image.


If you're enabling the experimental permissions model in Node.js, then you'd have to explicitly run the Node.js runtime with the aforementioned `--allow-child-process` command-line flag, because behind the hood, the `pdf-image` library spawns a child process to convert these PDFs.


While the Node.js Permissions Model provides a great way to restrict access to system resources, it's also crucial to be aware of potential security vulnerabilities in the packages we use. That's where the [Snyk extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=snyk-security.snyk-vulnerability-scanner) comes in. The Snyk extension can detect insecure code and vulnerable dependencies in a Node.js application. For example, the `pdf-image` package mentioned earlier is known to be vulnerable to command injection due to its use of child processes. This vulnerability has been known since 2018 and, unfortunately, there is no fix available as of yet.


This highlights the importance of using tools like Snyk to stay informed about security vulnerabilities in the packages we depend on. It's also a reminder that we must be mindful of how we use certain features, such as child processes, which can pose security risks if not handled properly.


As Node.js developers, we have a responsibility to ensure that the code we write is not only functional but also secure. One crucial way to enhance the security of a Node.js application is by using the built-in permissions model to restrict access to system resources during runtime. If you know that your Node.js application does not require any child process capabilities, do not enable this resource to avoid creating a bigger attack surface.


  

### FAQ on the Node.js Permissions Model


  

2. Implement input validation with a Fastify JSON schema
--------------------------------------------------------


[Input validation](https://learn.snyk.io/lesson/improper-input-validation/) is a crucial aspect of backend development. If you've built APIs before with Express, Fastify, or other frameworks, you've probably realized the importance already. It is a security practice that ensures that only properly formatted data enters your system, thereby preventing potential security risks. One such way to implement input validation in your Node.js applications is by using the Fastify schema for your Fastify web applications.


### Fastify schema-based approach


Fastify uses a schema-based approach for input validation. While it's not mandatory, it's recommended to leverage the JSON schema to validate your routes and serialize your outputs. JSON schema provides a contract for your data, detailing the expected data format, data types, mandatory fields, and other constraints. You can think of the Fastify route's JSON schema as using TypeScript to ensure strong typing in your code during the build process.


Consider a simple Fastify application where we are creating a new user. We can use a Fastify schema to validate the input data.



```
const fastify = require('fastify')({ logger: true });

const UserSchema = {
  body: {
    type: 'object',
    properties: {
      name: { type: 'string' },
      email: { type: 'string', format: 'email' },
      password: { type: 'string', minLength: 8 }
    },
    required: ['name', 'email', 'password']
  }
};

// User creation route
fastify.post('/users', { schema: UserSchema }, async (request, reply) => {
  // Example user creation logic
  // In a real application, you would replace this with actual database logic
  const user = request.body;

  // Simulating user creation
  console.log("Creating user:", user);

  // Responding with the created user (in real applications, never send the password back)
  return reply
    .code(201)
    .send({ success: true, message: "User created", user: { name: user.name, email: user.email } });
});

// Server startup
const start = async () => {
  try {
    await fastify.listen({ port: 6000, host: 'localhost' });
    console.log(`Server running at http://localhost:3000/`);
  } catch (err) {
    fastify.log.error(err);
    process.exit(1);
  }
};

start();
```

In the above code, we define a `UserSchema` that requires a name, email, and password. The email must be in a valid email format, and the password must be at least 8 characters long.


Neglecting input validation can expose your application to various security risks, including [server-side request forgery (SSRF)](https://learn.snyk.io/lesson/ssrf-server-side-request-forgery/) or [HTTP parameter pollution attacks](/blog/remediate-javascript-type-confusion-bypassed-input-validation/). SSRF attacks can trick the server into making unauthorized requests, potentially leading to data exposure, while HTTP parameter pollution can manipulate or corrupt requests, leading to unexpected behavior.


Tools like [Snyk](https://app.snyk.io) can help uncover these vulnerabilities by scanning your code for security flaws. They can also provide remediation advice to help you address these vulnerabilities, enhancing your application's overall security.


### FAQ on input validation with Fastify


  

3. Secure password hashing with Bcrypt
--------------------------------------


Storing user passwords securely is crucial in software development. In the event of a data breach, you want to ensure that the user's password information is not easily deciphered. This is where password hashing comes in. Hashing is the process of converting a given key into another value. A hash function is used to generate the new value, which should ideally provide a unique output (or hash code) for each unique input value.


If you decide to implement authentication by yourself instead of relying on a service or another library, it's vital to understand that the way you handle password security can directly affect your application's overall security.


### Introduction to Bcrypt for password hashing in Node.js


Bcrypt is an algorithm and an npm package that provides a password-hashing function that is considered to be very secure. It incorporates a salt (random data) to protect against rainbow table attacks and provides a work factor configuration, which allows you to determine how CPU-intensive the hashing will be — a useful feature to prevent brute-force attacks.


Let's explore a simple use case:



```
const bcrypt = require('bcrypt');
const saltRounds = 10;
const myPlaintextPassword = 'my_password';

bcrypt.hash(myPlaintextPassword, saltRounds, function(err, hash) {
  // Store hash in your password DB.
});
```

The `saltRounds` parameter determines the complexity of the hashing process. The higher the value, the longer the process takes, which can help safeguard against brute-force attacks. The `hash` function automatically salts and hashes the plaintext password. The resulting hash can then be stored in your database.


### FAQ on password hashing and auth management in Node.js


  

4. Prevent SQL injection attacks with Knex.js
---------------------------------------------


[SQL injection](https://learn.snyk.io/lesson/sql-injection/) is a prevalent security vulnerability that poses a significant risk to application data. Node.js developers can mitigate this risk by using Knex.js, a promising SQL query builder, to create safer SQL queries. However, note that Knex.js also allows building and running raw SQL queries, in which case, SQL injection is still a security issue as it may flow into the query when concatenating user input.


Knex.js is a powerful SQL query builder for Node.js. It supports transactions, connection pooling, migrations, and seeds, making it a preferred choice for developers seeking to write secure, robust, and scalable SQL queries. Knex.js safeguards against SQL Injection attacks by using parameterized queries and escaping values that are entered into the SQL statements.


Consider the following code snippet that demonstrates how Knex.js protects against SQL injection attacks:



```
const knex = require('knex')({
  client: 'pg',
  connection: {
    host : '127.0.0.1',
    user : 'your_database_user',
    password : 'your_database_password',
    database : 'myapp_test'
  }
});

// This value is provided by the user and could be malicious
// such as applying an OR 1=1 SQL injection or other
// techniques that escape the original context of the query
// and create a new one
let userProvidedValue = 'maliciousValue';

knex('users')
  .where('id', '=', userProvidedValue)
  .select()
  .then(rows => {
    // process result
  })
  .catch(err => {
    // handle error
  });
```

In this example, the `userProvidedValue` is automatically escaped by Knex.js, preventing any potential SQL Injection attack.


As we said before, using Knex.js by itself isn't a complete sandbox and security mitigation against SQL injection. Here's an example of a potentially insecure Knex.js usage that could lead to a SQL injection attack:



```
knex.raw(`SELECT * FROM users WHERE id = ${userProvidedValue}`)
```

In this case, the `userProvidedValue` isn't escaped or parameterized, making the query susceptible to SQL injection if the `userProvidedValue` contains malicious SQL code. Snyk can [help developers detect such vulnerabilities](/product/snyk-code/) in their codebase. Snyk scans your code and provides actionable insights to fix security vulnerabilities, including potential SQL injection attacks.


  

### FAQ on SQL injection prevention with Knex.js


  

5. Implement rate limiting with fastify-rate-limit
--------------------------------------------------


Rate limiting is a crucial security mechanism that protects your web applications against denial of service (DoS) attacks. By controlling the number of requests a client can make to your application within a specific timeframe, you prevent rogue clients from overwhelming your server with a large number of requests, thus ensuring that your application remains available to other legitimate users.


[fastify-rate-limit](https://github.com/fastify/fastify-rate-limit) is a plugin for the Fastify web framework that provides an easy-to-use interface for implementing rate limiting in your Node.js applications. The plugin lets you specify the maximum number of requests a client can make within a specific timeframe and the response to send when this limit is exceeded.


Here's a basic example of how you can implement rate limiting in your Node.js application using `fastify-rate-limit`:



```
const fastify = require('fastify')()

fastify.register(require('@fastify/rate-limit'), {
  // max number of connections during windowMs milliseconds before sending a 429 response
  max: 100,
  timeWindow: '1 minute'
})

fastify.get('/', (req, reply) => {
  reply.send({ hello: 'world' })
})

fastify.listen(3000, err => {
  if (err) throw err
  console.log('Server listening at http://localhost:3000')
})
```

In this code snippet, Fastify's rate limit package is configured to limit each client to 100 requests per minute. If a client exceeds this limit, the server responds with a 429 ("Too Many Requests") status code.


### FAQ on rate limiting


  

### **Why developers should use Snyk for JavaScript security**


In this blog post, we have covered five essential Node.js security code snippets that every backend developer should be familiar. We mentioned the importance of secure coding practices such as avoiding SQL injection and how they play a significant role in enhancing application security. With the evolution of technology and the increasing complexity of cyber threats, the need for secure coding cannot be overstressed.


As a developer, it is crucial to leverage robust security tools that can help identify and mitigate potential vulnerabilities in your code. One such tool is Snyk, a powerful developer security platform that offers developers the ability to detect and fix vulnerabilities in code, dependencies, containers, and more. With Snyk, you can continuously monitor your application for security vulnerabilities and receive automatic fix PRs when a new vulnerability is discovered.



```
// Install Snyk CLI
npm install -g snyk

// Then run Snyk to find vulnerabilities
snyk test
```

Snyk integrates seamlessly into your [IDEs](/platform/ide-plugins/) and [CI/CD pipeline](/platform/ci-cd-pipeline-security/), enabling you to maintain continuous security throughout your application development lifecycle. It supports a wide range of programming languages, including Node.js, making it a versatile tool for developers across different platforms.


Secure coding is a fundamental practice in software development that every backend developer should prioritize. The use of security tools like Snyk further enhances this practice by providing automated vulnerability detection and remediation capabilities. As we continue to navigate the ever-evolving landscape of cyber threats, these practices and tools will be vital in maintaining the security and integrity of our applications.