SQL Injection (SQLi)
An attack that smuggles malicious SQL into a query because user input was concatenated into it — decades old, still devastating, and fully preventable with parameterized queries.
What is SQL injection?
SQL injection (SQLi) is an attack where an attacker inserts malicious SQL into an application’s database query by supplying crafted input, because the application built its query by concatenating user input directly into SQL text. Instead of treating input as data, the database ends up executing it as part of the command. The classic illustration: a login query built as "SELECT * FROM users WHERE name='" + input + "'" becomes catastrophic when the input is ' OR '1'='1, turning the condition always-true and bypassing authentication. SQLi is one of the oldest web vulnerabilities and, embarrassingly, still one of the most common and damaging.
Why it happens and what it enables
The root cause is a failure to separate code from data — the application blurs the line between the query’s fixed logic and the user’s untrusted input, so the attacker’s input redraws that line. The consequences are severe and go well beyond auth bypass: attackers can read entire databases (dumping every user’s credentials, personal data, payment info), modify or delete data, escalate privileges, and in some configurations execute commands on the underlying server. Many of history’s largest data breaches trace back to SQLi. It sits on the OWASP Top 10 (under Injection) precisely because it’s both prevalent and high-impact. Variants include blind SQLi (no visible error output, so attackers infer data from timing or boolean responses) and second-order SQLi (malicious input stored, then later used unsafely).
The fix is known and near-total: parameterized queries
Unlike many security problems, SQLi has a definitive, well-understood fix: parameterized queries (prepared statements). With parameterization, the SQL structure is sent to the database first, with placeholders, and the user input is sent separately as pure data that can never be interpreted as SQL — the code/data separation is enforced by the database engine itself, not by fragile escaping. Virtually every language and framework supports this (and ORMs use it under the hood), which is why SQLi is considered almost entirely preventable. Supporting defenses add depth: input validation (allow-listing expected formats), least-privilege database accounts (so a compromised query can’t drop tables), and a WAF to catch known patterns — but these are backups. The one anti-pattern to eliminate everywhere is string-concatenating user input into queries; escaping by hand is error-prone and not a substitute for parameterization.
What people get wrong
- Manual escaping instead of parameterized queries — hand-rolled escaping misses edge cases; prepared statements are the actual fix.
- Trusting “hidden” inputs: hidden fields, headers, cookies, and API parameters are all attacker-controllable — validate and parameterize everywhere.
- Over-privileged DB accounts — running app queries as an admin turns a single injection into full-database compromise; use least privilege.
Primary source: OWASP: SQL Injection
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.