What Is SQL Injection? The Attack and the Fix

SQL injection is a vulnerability where untrusted input gets concatenated directly into a SQL query string, letting an attacker change what the query actually does. It’s one of the oldest web application vulnerabilities still found in production systems, and the fix has been well understood for decades — the vulnerability persists mostly where raw string concatenation sneaks past code review.

How the injection works

Consider a login check built by concatenating a username straight into a query:

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

If username and password come from a form and the application trusts them as plain text, an attacker can submit a username of:

' OR '1'='1

The resulting query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

'1'='1' is always true, so the WHERE clause matches every row, and the application often just logs in as the first user returned — frequently an administrator. That’s the classic example, but the same technique extends to reading arbitrary tables (UNION SELECT), extracting data one character at a time when no output is shown (blind injection, inferred from response timing or true/false behavior), or in the worst configurations, executing operating-system commands through database-specific extensions.

Why string concatenation is the root cause

The vulnerability exists because the application asks the database to parse a string that mixes two things that should never share a channel: the fixed structure of the query, and the caller-supplied data. The database has no way to tell where the intended data ends and injected SQL syntax begins — from its perspective, it just received one query string and ran it.

The fix: parameterized queries

Parameterized queries (also called prepared statements) fix this by sending the query structure and the data separately. The database compiles the query template first, with placeholders standing in for values, and only afterward binds the actual data into those placeholders — as data, never as executable SQL syntax.

const query = "SELECT * FROM users WHERE username = ? AND password_hash = ?";
db.execute(query, [username, passwordHash]);

Here, no matter what string an attacker puts in username, it’s bound as a literal value for that placeholder. A username of ' OR '1'='1 is compared literally against the username column — it can’t restructure the query, because the query’s structure was already fixed before the data arrived. Every mainstream database driver and ORM supports parameterized queries; there’s essentially never a legitimate reason to build a SQL string by concatenating untrusted input into it.

What doesn’t fully fix it

A few common mitigations reduce risk but aren’t substitutes for parameterization:

• Escaping special characters (quotes, backslashes) manually is error-prone — different databases and contexts escape differently, and it’s easy to miss a case. Use your driver’s parameterization, not a hand-rolled escape function.
• Input validation (rejecting unexpected characters) is useful defense-in-depth but shouldn’t be the only layer — legitimate data (a name like O'Brien) can contain characters that also appear in attacks, so validation alone can’t distinguish safe from malicious.
• ORMs generally parameterize queries automatically for their standard query-building methods, but most also offer an escape hatch for raw SQL — that escape hatch reintroduces the exact same risk if untrusted input is concatenated into it.

Least privilege as a second layer

Even with parameterized queries everywhere, it’s worth limiting what damage a successful injection (from a bug you haven’t found yet, or a dependency vulnerability) could do. The application’s database user should hold only the permissions it actually needs — a web app that never runs DROP TABLE shouldn’t have a database role that’s allowed to. Connection pooling setups often centralize credentials in one place, which makes this kind of least-privilege configuration easier to enforce consistently across services.

SQL injection vs other injection-style attacks

SQL injection is one member of a broader family of vulnerabilities where untrusted input is interpreted as code or commands instead of data. Cross-site scripting is the same root problem applied to HTML/JavaScript output instead of SQL, and CSRF is a related but distinct attack that abuses authenticated sessions rather than injecting code. A web application firewall can catch some SQL injection attempts by pattern-matching request bodies, and it’s a reasonable extra layer at the edge — but it’s a mitigation for defense-in-depth, not a replacement for parameterized queries in the application itself, since attackers routinely find WAF bypass encodings.

The takeaway

SQL injection happens when untrusted input gets concatenated into a query string instead of passed as bound data, letting an attacker rewrite the query’s logic. Parameterized queries close the vulnerability at the source by keeping query structure and data on separate channels, and every mainstream database driver supports them — there’s rarely a good reason to reach for raw string concatenation instead. Least-privilege database credentials and a WAF add useful defense-in-depth, but they’re backstops, not fixes for the underlying pattern.