Skip to content
tezvyn:
Menu

Preventing SQL Injection: Never Trust User Input

Source: cheatsheetseries.owasp.orgEasyHow cards are made

To prevent SQL injection, treat SQL as a template and user input as data that can only fill placeholders, never changing the query's structure. Use this for any database query in your Node.js app that uses external data.

Why it exists

SQL Injection exists because developers sometimes mix data with code. If user input (data) is concatenated directly into a SQL query string (code), an attacker can provide malicious input that changes the query's logic, allowing them to bypass authentication, steal data, or even destroy the database.

The mental model

Think of your SQL query as a form letter with blank spaces, like "Dear __, you have won __ dollars!". User input is the data used to fill in those blanks. Parameterized queries ensure that the input ('John Smith', '100') can only be treated as data for the blanks, never as part of the letter's structure itself.

How it works

The correct defense is to use parameterized queries, also known as prepared statements. Your application sends the SQL command to the database server with placeholders (like ? or $1) instead of the actual user data. In a separate step, it sends the user's data. The database engine first parses and compiles the query's structure, then safely inserts the data into the placeholders. Because the query's logic is already locked in, the data cannot be executed as a command.

When to use it

Always. Every time your Node.js application constructs a SQL query that includes variable data, especially data originating from an external source like a user's browser, an API call, or a file. There is no performance penalty significant enough to justify avoiding them.

When not to use it

There is no valid reason to avoid parameterized queries when dealing with external data. Manually building queries via string concatenation is an anti-pattern. Even for dynamic queries where column or table names must change, those names should come from a hardcoded allow-list, not directly from user input.

One canonical example

Imagine a user login in an Express app. The VULNERABLE way uses string concatenation: const query = "SELECT FROM users WHERE username = '" + req.body.username + "'";. An attacker could enter ' OR '1'='1 as the username, making the query ...WHERE username = '' OR '1'='1', which is always true, bypassing the login. The SECURE way uses parameterization (e.g., with the mysql2 library): const sql = "SELECT FROM users WHERE username = ?"; db.query(sql, [req.body.username]);. Here, the malicious input is treated as a literal string, and the database correctly finds no user with that name.

Interview question

Which of the following best describes how parameterized queries prevent SQL injection vulnerabilities?

  • a.They execute user input in a sandboxed environment first to check for malicious intent before allowing it into the main query.
  • b.They separate the SQL query's structure from user-provided data, ensuring the input is treated only as values for placeholders.Correct
  • c.They automatically filter out known malicious SQL keywords and characters from user input before query execution.
  • d.They encrypt all user-provided data before it is incorporated into the SQL query, making it unreadable to attackers.
Why?

Parameterized queries work by sending the SQL command structure and user data separately to the database. This ensures the database treats user input strictly as data to fill placeholders, preventing it from being executed as part of the query's logic. Filtering (option C) is an unreliable defense as it's difficult to catch all malicious inputs.

Just read this? Test yourself on what you have been reading.

Read the original → cheatsheetseries.owasp.org

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.

See open roles