SQL Injection

A database query is just text the application hands to a SQL engine like PostgreSQL or MySQL. SQL injection happens when part of that text comes from a user and the application glues it in raw. The attacker writes input that is not data but more SQL, so the engine runs commands the developer never intended.

The classic example is a login form. The app builds a query like SELECT * FROM users WHERE email = 'INPUT' AND password = 'INPUT'. If a user types ' OR '1'='1 into the email box, the query becomes WHERE email = '' OR '1'='1' AND ... which is always true, so the database returns every row and the attacker logs in as the first user, often an admin.

From there an attacker can read other tables (UNION SELECT to pull password hashes or credit card data), modify rows, drop tables, or in some setups run operating system commands. It is consistently one of the top entries in the OWASP Top 10 and has been behind major breaches for over two decades.

The root cause is that the database cannot tell the difference between the query the developer wrote and the data a user supplied once they are merged into one string. The parser sees a single block of SQL and trusts all of it. Quote characters, comment markers like --, and statement separators like the semicolon become weapons because they let the attacker break out of the intended data slot and into the command structure.

Parameterized queries (also called prepared statements) close this gap by sending the query template and the values over separate channels. The app sends SELECT * FROM users WHERE email = $1 with a placeholder, then sends the actual email value separately. The database compiles the query plan first, so the value can only ever be treated as data. Even ' OR '1'='1 just becomes a literal string the engine searches for, and the search simply finds no matching email.

Two related flavors matter in practice. Blind SQL injection is when the app does not show query results or errors, so the attacker infers data one bit at a time by watching whether a page changes (boolean blind) or how long it takes to respond (time blind, using commands like SLEEP). Second-order injection is when malicious input is stored safely once, then later concatenated into a different query that does not escape it.

The primary defense is parameterized queries everywhere user input touches SQL. Most languages and ORMs do this by default: in Python use psycopg with cursor.execute(query, params), in Node use the pg library with $1 placeholders, in Java use PreparedStatement. An ORM like Drizzle, Prisma, or Hibernate generates parameterized SQL for you, which is why ORMs cut down injection bugs, but the protection breaks the moment you drop to raw string SQL or build a query with string concatenation.

Input validation and allowlisting help as a second layer, especially for things that cannot be parameterized such as table names, column names, or ORDER BY directions. For those, check the value against a fixed list of permitted names rather than escaping it. Escaping input by hand is fragile and easy to get wrong across different databases, so it should be a last resort, not the main strategy.

Defense in depth limits the damage if injection still happens. Give the application database account only the privileges it needs (a read API user should not be able to DROP tables), put a web application firewall in front to catch obvious payloads, and turn off detailed SQL error messages in production so attackers cannot use them to map your schema. The cost of all this is mostly discipline, not performance, since prepared statements are usually as fast or faster because the database caches the compiled plan.

In 2008 Heartland Payment Systems was breached through SQL injection on a web form, leading to the theft of more than 130 million credit card numbers, one of the largest card breaches of its era. The attackers used the injected access as a foothold to plant malware deeper in the network.

The 2011 Sony Pictures breach by LulzSec also started with a single unparameterized query. The group pulled over a million user accounts, and Sony had stored many passwords in plain text, which turned a query bug into a full credential dump. The lesson engineers took from it was that injection plus poor data hygiene multiply each other.

These were not exotic attacks. Both came down to a query that pasted user input straight into SQL. A single parameterized statement on the vulnerable form would have stopped the initial entry, which is why the rule never concatenate user input into SQL is treated as non-negotiable in code review today.