SQL injection happens when an application builds a database query by pasting untrusted input directly into the SQL string, so an attacker who sends carefully shaped input can change what the query does instead of just supplying a value. For beginners, that one sentence is the whole concept: the database cannot tell your intended query apart from the attacker's addition, because to the database it is all one string. Everything else is detail. It has sat near the top of the OWASP list of web risks for two decades precisely because the mistake is so easy to make and the payoff for attackers is so large.
This guide explains the mechanism and the defense conceptually. There are no working payloads aimed at real systems here — the point is to understand the class well enough to never write vulnerable code, and to recognize it in review.
The mechanism, in one example
Imagine a login lookup written by concatenation:
// vulnerable: user input is glued into the SQL text
String sql = "SELECT * FROM users WHERE email = '" + email + "'";
statement.executeQuery(sql);
If email is a normal address, the query behaves. But the value is not treated as data — it is treated as part of the command. A supplied value that closes the quote early and adds its own clause becomes executable SQL. The classic illustration is an input that always evaluates true, turning a "find this one user" query into "return every user." The database did exactly what the assembled string told it to; the application simply assembled a string it did not intend.
That is the entire vulnerability. The variety of consequences — reading other tables, bypassing authentication, in some configurations modifying or deleting data — all flow from the same root: input crossed from the data lane into the command lane.
Why validation alone is not the fix
Beginners often reach first for blocklists: strip apostrophes, ban the word SELECT, escape a few characters. This is a trap. Attackers have endless encodings, comment tricks, and case variations, and every blocklist has a gap. Escaping by hand is fragile for the same reason. Input validation is worth doing — reject an email that is not shaped like an email — but you do it to enforce business rules, not as your injection defense. The actual fix works at a different layer.
The real fix: parameterized queries
Parameterized queries (also called prepared statements) keep the SQL text and the data in separate channels. You write the query with placeholders, then hand the values to the driver separately. The driver sends the query structure to the database once, and the values never get parsed as SQL — they are bound as parameters, so an apostrophe or a keyword in the input is just literal text.
// safe: structure and data travel separately
String sql = "SELECT * FROM users WHERE email = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, email);
ResultSet rs = ps.executeQuery();
}
Every mainstream language has the equivalent. In Python's sqlite3 or psycopg, pass parameters as the second argument to execute rather than formatting them into the string. In Node with pg, use $1 placeholders and a values array. The rule is identical everywhere: never build a query with string formatting or concatenation using untrusted input. If your ORM or query builder covers a case, use its parameter binding; if you must write raw SQL, use placeholders.
There is one gap parameters cannot cover: identifiers like table or column names cannot be bound as parameters. If those must be dynamic, validate them against a fixed allowlist of known-good names — never pass a raw string through.
Defense in depth
Parameterized queries close the primary hole. A few more habits limit the damage if something slips through:
- Least privilege for the database account. The app's login user should have exactly the rights it needs and no more. A read path that connects with a read-only account cannot be tricked into dropping a table.
- Least data on error. Do not return raw database errors to the client. Verbose errors hand an attacker a map of your schema.
- Automated review. Static analysis and code review catch concatenated queries before they merge. Injection flaws in your own code are a SAST and review concern; injection flaws in a database library you depend on are a dependency concern. A tool such as Safeguard can surface a data-access library with a known advisory, which our SCA overview explains, while the Academy covers secure coding patterns for query building in more depth.
Finding it in a codebase
To audit for injection, grep for the string operations that build SQL: concatenation with +, format strings, template literals, and interpolation inside anything that reaches a database call. Every one of those is a candidate. Then confirm whether the interpolated value can originate from a request. The mechanical tell is simple — a query string that is not a constant. Modern frameworks make the safe path the easy path, so the vulnerable ones usually stand out as older, hand-written data access.
FAQ
What is SQL injection in one sentence?
It is when untrusted input is placed directly into a SQL query string, letting an attacker alter the query's logic instead of merely supplying a value, because the database parses the whole string as one command.
Do parameterized queries fully prevent SQL injection?
For values, yes — bound parameters are never parsed as SQL. The one exception is dynamic identifiers such as table or column names, which cannot be parameterized and must be checked against an allowlist instead.
Is input validation enough to stop SQL injection?
No. Blocklisting characters or escaping by hand is fragile and repeatedly bypassed. Validation enforces business rules; parameterized queries are the actual defense. Use both, but rely on parameters.
Does an ORM protect me automatically?
Mostly. ORMs use parameter binding for standard operations, so ordinary queries are safe. Risk returns the moment you drop to raw SQL or string-build a query fragment — those still need placeholders.