Node.js SQL Injection Guide: Examples and Prevention

Node.js continues to be a powerful runtime platform for developing accessible and scalable applications, backed by major tech companies and a thriving ecosystem. While Node.js offers tremendous flexibility and benefits, it remains vulnerable to common web application security threats like SQL injection when not properly secured. Understanding and preventing these vulnerabilities is crucial for modern application security.

This comprehensive guide will examine SQL injection attacks in Node.js applications and provide current best practices for prevention using the latest tools and libraries available in 2025.

What is SQL Injection?

SQL injection is a code injection technique that exploits security vulnerabilities in database layer implementations. Attackers inject malicious SQL code through user input fields, potentially gaining unauthorized access to data, manipulating database contents, or even taking control of the entire database system.

The primary causes of SQL injection vulnerabilities include:

• Poor input validation and sanitization
• Dynamic SQL query construction using string concatenation
• Insufficient use of parameterized queries
• Lack of proper access controls and the principle of least privilege

Given that successful SQL injection attacks can expose sensitive data, corrupt databases, or provide system access, the potential impact is severe. Despite their serious consequences, many SQL injection attacks are surprisingly simple to execute, making prevention all the more critical.

SQL Injection Examples in Node.js

Let’s start by examining a typical login endpoint that’s vulnerable to SQL injection embedded within an Express application. This example illustrates how developers frequently make the mistake of directly concatenating user input into SQL queries, thereby creating a serious security hole.

app.post('/login', (req, res) => {

  const { username, password } = req.body;

  const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

  connection.query(query, (err, results) => {

    if (err) throw err;

    if (results.length > 0) {

      res.json({ success: true, user: results[0] });

    } else {

      res.status(401).json({ success: false, message: 'Invalid credentials' });

    }

  });

});

Within this code, one single line leads to the SQL injection vulnerability:

const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

This line directly inserts user input into the SQL query using template literals. An attacker can exploit this by providing malicious input that changes the query’s logic entirely. This means that if an attacker provides these inputs:

• Username: admin’ OR ‘1’=’1′; —
• Password: anything

The raw text is fed directly in, and the resulting query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1'; --' AND password = 'anything'

Once executed on the database, here’s what happens:

• ‘1’=’1′ is always true, making the entire WHERE condition true
• — comments out the password check

The query now returns all users instead of checking the credentials for a specific user. This is why we now have plenty of tools at our disposal to prevent these attacks.

Common SQL Injection Attack Patterns

Understanding these common attack patterns helps developers recognize potential vulnerabilities. There are quite a few patterns that could be used within a SQL injection attack. Almost all can be avoided through ORM use or simply using parameterized queries, which we will cover later. Here are some of the most common you’ll see:

Always True Conditions

As we already saw in our initial example, attackers can use conditions that always evaluate to true to bypass authentication. The generated SQL query will look like this:

SELECT * FROM users WHERE id = 1 OR 1=1;

Union-Based Attacks

Another way attackers can bypass the intended query is to combine results from different tables to extract sensitive data. In these cases, the resulting query run against the database will look like this:

SELECT name FROM products WHERE id = 1 UNION SELECT password FROM users;

Time-Based Blind Injection

When direct data extraction isn’t possible, attackers use time delays to infer information. An example of this would look like so:

SELECT * FROM users WHERE id = 1 AND (SELECT COUNT(*) FROM users WHERE SUBSTRING(password,1,1) = 'a') > 0 AND SLEEP(5);

In this case, although slightly confusing, the user can infer a condition’s truth based on the speed of the result’s return. It’s more roundabout but also just as effective.

Boolean-Based Blind Injection

Similar to the time-based blind injection attack above, attackers can use true/false conditions to gradually extract data:

SELECT * FROM users WHERE id = 1 AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') = 'a';

All of these attacks happen when user input is directly concatenated into the query string. Preventing attackers from injecting commands into the query string directly is the best way to avoid this from happening. Let’s look at some of the best ways to do this.

How to Prevent SQL Injection

When it comes to preventing SQL injection, the primary defense is making sure that raw text is not directly added into a query string and executed. This approach generally works best when input validation and sanitization are implemented, along with the use of ORMs and query builders, ensuring that anything that slips through initial checks cannot be used in an injection attack. Let’s look at some of the most common ways to prevent SQL injection.

Use Modern ORMs and Query Builders

The Node.js ecosystem offers excellent ORMs that provide built-in SQL injection protection through type safety and automatic parameterization. Modern ORMs eliminate the need to write raw SQL in most cases, and when you do need custom queries, they provide safe mechanisms for parameterization. Two of the most popular options for this in the Node.js world are Prisma and Drizzle.

Prisma

Prisma greatly reduces SQL injection risk when using its query API, as it automatically parameterizes input. Raw query APIs should still be used with care. For example, let’s say we initially had some code that was vulnerable to SQL injection that looked like this:

const query = `SELECT * FROM users WHERE email = '${email}'`;

connection.query(query, callback);

With Prisma, we would simply rewrite this so that it looks like this:

const user = await prisma.user.findFirst({

  where: { email: email }

});

While maintaining the same functionality, no string concatenation is possible due to automatic parameterization and compile-time type safety that Prisma provides.

Drizzle ORM

Another popular ORM that has been rising up through the ranks is Drizzle. This choice is perfect for developers who prefer SQL-like syntax over more proprietary syntax, such as that used with Prisma. Similar to our last example, imagine that we had the following vulnerable line in our application that is directly concatenating raw strings into a SQL command:

const query = `SELECT * FROM users WHERE email = '${email}' AND status = '${status}'`;

With Drizzle, we could then securely replicate this exact line without the vulnerability. With SQL-like syntax, here is what the line above would become:

const user = await db.select().from(users)

  .where(and(eq(users.email, email), eq(users.status, status)));

This allows Drizzle to deliver syntax that is familiar to SQL users with automatic parameterization through operator functions. If you don’t want to use an ORM, you can also do similar types of logic using parameterized queries with native drivers as well. We will cover that approach next.

Parameterized Queries with Native Drivers

When using native database drivers directly, parameterized queries are your primary defense against SQL injection. The key principle is to never concatenate user input directly into SQL strings. Instead, use placeholder values that are safely handled by the database driver.

Modern Node.js database drivers provide excellent support for parameterized queries, automatically escaping and handling data types to prevent injection attacks. For example, let’s once again look at a vulnerable line of code that directly injects a string into a SQL query:

const query = `SELECT * FROM users WHERE id = ${userId}`;

connection.query(query, callback);

Now, using parameterized queries, we can safely query against the database without needing to worry about SQL injection. For instance, here are two popular examples using the MySQL2 client package for those querying against MySQL and the Node-Postgres client package for Postgres users.

// MySQL2

connection.execute('SELECT * FROM users WHERE id = ?', [userId], callback);

// PostgreSQL

pool.query('SELECT * FROM users WHERE id = $1', [userId], callback);

Similar to using an ORM, Input is sent separately from SQL, with automatic escaping and type safety. This approach works since the database driver handles the user input as data, not as executable SQL code, making injection impossible regardless of the input content.

Input Validation and Sanitization

Input validation is one of your strongest defenses against SQL injection when combined with parameterized queries. It involves comprehensive type validation, sanitization, and transformation that catches malicious input before it ever reaches your database queries. The key principle is to validate not just the presence of data, but its exact type, format, and constraints.

There are two main approaches in the Node.js ecosystem: schema-based validation with libraries like Zod and middleware-based validation with express-validator. Both provide excellent protection when implemented correctly.

Schema-Based Validation with Zod

Zod is a TypeScript-first validation library that provides runtime type validation matching your compile-time checks. It’s particularly powerful because it validates data type, format, and constraints in a single step, acting as a security gateway for your application. For example, you could define a schema, such as userSchema, and then parse input against it. If the validation fails, then any logic downstream will not get executed (such as with the try/catch below).

import { z } from 'zod';

const UserSchema = z.object({

  email: z.string().email().max(255),

  name: z.string().min(1).max(100).regex(/^[a-zA-Z\s]+$/),

  age: z.number().int().min(18).max(120),

});

app.post('/users', async (req, res) => {

  try {

    const userData = UserSchema.parse(req.body);

    const user = await prisma.user.create({

      data: userData,

    });

    res.json(user);

  } catch (error) {

    if (error instanceof z.ZodError) {

      res.status(400).json({ 

        error: 'Validation failed', 

        details: error.errors 

      });

    } else {

      res.status(500).json({ error: 'Internal server error' });

    }

  }

});

You’ll see in the example for the name field that a regex is being used, like so:

name: z.string().min(1).max(100).regex(/^[a-zA-Z\s]+$/)

The regex pattern /^[a-zA-Z\s]+$/ explicitly allows only letters and spaces, blocking SQL injection attempts that rely on special characters, quotes, or SQL keywords. This acts as a pre-filter before any further lines, like those containing the SQL logic, can be executed.

Middleware-Based Validation

For applications that prefer Express middleware patterns, express-validator offers similar protection with automatic sanitization. Similar to the Zod example above, below is how a similar validation can be done with this alternative:

import { body, validationResult } from 'express-validator';

const validateUser = [

  body('email').isEmail().normalizeEmail().isLength({ max: 255 }),

  body('name').trim().isLength({ min: 1, max: 100 }).matches(/^[a-zA-Z\s]+$/),

  body('age').isInt({ min: 18, max: 120 }).toInt(),

];

app.post('/users', validateUser, async (req, res) => {

  const errors = validationResult(req);

  if (!errors.isEmpty()) {

    return res.status(400).json({ error: 'Validation failed', details: errors.array() });

  }

  // Input is now validated and sanitized

  const { email, name, age } = req.body;

  const user = await prisma.user.create({ data: { email, name, age } });

  res.json(user);

});

Regardless of which route you choose, both approaches provide strong SQL injection protection by ensuring malicious input never reaches your database queries. That said, you still need to make sure that you are using an ORM or parameterized queries, not solely relying on this validation as your only prevention.

Type Checking and Runtime Validation

Even with parameterized queries, type confusion attacks can occur when attackers send unexpected data types. This means that you always validate input types at runtime. For example, this endpoint below could be vulnerable to injection even though it is using a parameterized query:

app.post('/search', (req, res) => {

  const { userId } = req.body; // Could be anything!

  connection.query('SELECT * FROM posts WHERE user_id = ?', [userId], callback);

});

Even with parameterized queries, you should validate input types at runtime. While parameterization prevents SQL injection by treating user input as data, type validation ensures your application logic behaves as expected and helps prevent unexpected errors or logic flaws.

For example, suppose your endpoint expects a numeric ID, but your application logic makes decisions based on the value’s type or format. Without validation, unexpected input could cause unintended behavior or errors.

Here’s how you can validate and enforce numeric input with Zod before it ever reaches your SQL logic:

import { z } from 'zod';

const IdSchema = z.string().regex(/^\d+$/).transform(Number);

app.post('/search', (req, res) => {

  try {

    const userId = IdSchema.parse(req.body.userId);

    connection.query('SELECT * FROM posts WHERE user_id = ?', [userId], callback);

  } catch (error) {

    res.status(400).json({ error: 'Invalid user ID' });

  }

});

Doing this helps to prevent object injection, ensures expected data types, and fails safely on invalid input. While this won’t turn an object like {“userId”: {“$ne”: null}} into a SQL injection in a parameterized query, it will prevent malformed or unexpected data from being processed. This keeps your queries predictable and reduces the risk of logic errors that attackers might exploit.

Database Access Controls

Implementing an overall data hygiene and safety practice to prevent injection attacks involves assigning proper database user permissions. Although you’ll still want to make sure SQL execution in your code is secure, dialing in the access to a database creates an additional security layer that limits damage even if SQL injection occurs. For example, you could create users like so:

-- Create a dedicated database user with limited permissions

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'secure_password';

-- Grant only necessary permissions

GRANT SELECT, INSERT, UPDATE ON app_db.users TO 'app_user'@'localhost';

GRANT SELECT, INSERT, UPDATE ON app_db.posts TO 'app_user'@'localhost';

-- Deny dangerous operations

REVOKE DROP, ALTER, CREATE, INDEX ON app_db.* FROM 'app_user'@'localhost';

Following the Principle of Least Privilege, you can see that specific users are only granted the necessary permissions on certain tables, nothing more. For example, our ‘app_user’@‘localhost’is only allowed to do SELECT, INSERT, UPDATE ON app_db.users. Your application user only gets the permissions it needs. Even if an attacker injects SQL, they can’t drop tables or create new database objects.

You could also add in explicit denial of certain operations as well, such as:

REVOKE DROP, ALTER, CREATE, INDEX ON app_db.* FROM 'app_user'@'localhost';

Explicitly removing dangerous permissions ensures that even future permission grants won’t accidentally include them.

Security Headers and Environment Configuration

Lastly, most modern applications need a comprehensive security configuration including headers, rate limiting, and environment-based settings.  While security headers and environment-based configuration do not directly prevent SQL injection, they play an important role in your overall security posture. Features like HTTP security headers, rate limiting, and TLS configuration help mitigate other attack vectors (such as brute-force attacks or reconnaissance) that attackers might use to discover SQL injection points.

For example, using Helmet in Express:

import helmet from 'helmet';

app.use(helmet());

Helmet adds headers like Content-Security-Policy and X-Frame-Options that help block common browser-based exploits.

Similarly, rate limiting can slow down automated scanning tools:

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({

  windowMs: 15 * 60 * 1000, // 15 minutes

  max: 100,

  message: 'Too many requests from this IP',

});

app.use('/api/', limiter);

These steps won’t stop a SQL injection payload if it exists in your code; that’s the job of parameterized queries, ORMs, and input validation, but they help reduce the exposure of those vulnerabilities by limiting attack opportunities. Of course, another popular and easier solution for this type of defense is to use an API gateway instead, which offers all of this functionality and more.

Automated SQL Injection Testing with StackHawk

If you’re new to StackHawk, let me give you a brief overview. StackHawk is a DAST tool (Dynamic Application Security Testing) that enables your team to integrate security testing into their traditional software testing workflows, providing AppSec teams with the peace of mind of controlled and security-tested applications in production. It specifically tests for SQL injection vulnerabilities along with other OWASP Top 10 security risks, including:

• SQL Injection Detection: Testing all input fields, parameters, and endpoints for potential SQL injection vulnerabilities
• Runtime Vulnerability Testing: Identifying security issues that only manifest when the application is running
• API Security Testing: Comprehensive testing of REST APIs, GraphQL, and other API endpoints
• Integration with Development Workflows: Seamless integration into CI/CD pipelines for continuous security testing
• Developer-Friendly Reporting: Clear, actionable vulnerability reports with remediation guidance

If you’re using an AI-coding assistant like Cursor or Claude Code, sign up for our $5/month single-user plan, Vibe, to find and fix vulnerabilities 100% in natural language.

Configure StackHawk

Now that our code is set up and our API is running, let’s get StackHawk to identify this vulnerability for us automatically. You’re going to want to sign up for an account if you don’t have one already.

Then, from there, click into the Applications screen and click Add Application:

If you’re new to StackHawk, you’ll be automatically brought into the Add an App flow. On the Scanner screen, you’ll see the instructions for installing the StackHawk CLI. Since we will be running our testing locally, we will use this option. Once the hawk init command is executed successfully, click the Next button.

On the next screen, you will fill out an Application Name, Environment, and URL. Once filled out, click App Type to proceed.

Since we will be testing a RESTful API, on the next page, we will choose our Application Type as “API”, the API Type as “REST / OpenAPI”, and point to our OpenAPI Specification file by selecting URL Path and adding our endpoint, /api-spec/, into the textbox. Once complete, click Next.

Lastly, we will need to add a stackhawk.yml file to the root of our project. Once the file is added, copy the screen’s contents, paste it into the file, and save it. Once complete, we can run the “hawk scan” command in a terminal pointing to the root of our project. Lastly, we can click the Finish button.

Run HawkScan

After running the “hawk scan” command in the previous step, you should see the tests beginning to execute in the terminal.

This will run tests against our API based on the OpenAPI spec using the OpenAPI Spider provided by StackHawk.

Explore the Initial Findings

Once the tests are complete, the terminal will contain some information about any vulnerabilities found. Below, we can see that it has identified the SQL injection vulnerability that we introduced in the code. To explore this further, we will click on the test link that is provided at the bottom of the output. This will take us into the StackHawk platform to explore further.

After clicking on the link, we can now see the test results nicely formatted. Next, we will click on the SQL Injection entry.

Within this entry, we can see an Overview and Resources that can help us with fixing this vulnerability, as well as the Request and Response that the API returned. Just above this, you will also see a Validate button, which will display a cURL command with the exact API request used to expose the vulnerability.

Fixing the SQL Injection Vulnerability

Now that we have identified the vulnerability, it’s time to fix it. To prevent SQL injection in the Node.js Express application, the easiest way is to modify the code to use parameterized queries or an ORM, as previously discussed. This approach ensures that user input is treated as data, not as part of the SQL command. Doing so prevents attackers from injecting malicious SQL code through user input. Make the necessary changes in your code, save the code, and restart the application to apply the changes.

Confirm the fix!

With the fix in place, let’s confirm it is working as intended. To do this, back in StackHawk, we will click the Rescan Findings button.

Then, we will see a modal containing the “hawk rescan” command that includes the correct Scan ID. You’ll run this command in the same terminal where you ran the initial set of tests.

In the output, you will again see any vulnerabilities found in the scan. In this case, you’ll see that the SQL injection vulnerability is no longer showing. Clicking on the link at the bottom of the terminal output, you can confirm that the SQL injection vulnerability has now been added to the Fixed Findings from Previous Scan, confirming that the vulnerability has been successfully fixed and has passed any vulnerability tests.

Conclusion

SQL injection remains a critical security threat in 2025, but modern Node.js development practices and tools provide robust protection when properly implemented. By combining modern ORMs like Prisma or Drizzle with comprehensive input validation, parameterized queries, and security monitoring, developers can build applications that are resistant to SQL injection attacks.

If you’d like to gain an understanding of SQL injection prevention in frameworks other than Node.js, check out one of our other guides:

• Django SQL Injection – Python web framework implementation
• .NET SQL Injection – Cross-platform web application security
• Spring SQL Injection – Java enterprise framework protection

The key to effective SQL injection prevention lies in adopting a defense-in-depth approach, using multiple layers of protection, and staying current with the latest security best practices and tool updates. Regular security audits, automated testing, and team training ensure that security remains a priority throughout the development lifecycle.

Remember that security is not a one-time implementation but an ongoing process that requires continuous attention and improvement as threats evolve and new vulnerabilities are discovered.

Ready to strengthen your application security? Take the next step by implementing automated security testing in your development workflow. Try StackHawk for free with a 14-day trial and start testing your Node.js applications for SQL injection vulnerabilities today. With StackHawk’s developer-friendly DAST platform, you can catch security issues before they reach production and build more secure applications with confidence.