What is SQL injection? The database attack explained
Last reviewed
SQL injection (SQLi) is a vulnerability where untrusted input is concatenated into a database query, letting an attacker change the query's logic. It can expose, modify, or delete data, bypass authentication, and sometimes run commands on the server. The fix is parameterized queries (prepared statements), which keep data separate from code.
What SQL injection is
SQL injection is one of the oldest and most damaging classes of web vulnerability, tracked as CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). It happens when an application builds a database query by mixing trusted command text with untrusted user input. Because the database cannot tell which characters were meant as data and which were meant as instructions, attacker-supplied characters can change what the query does.
Any data source the application does not control can be an injection point: form fields, URL parameters, HTTP headers, cookies, and even data read back from the database itself in second-order attacks.
How the attack works
Imagine a login query built by string concatenation: SELECT * FROM users WHERE username = '$user' AND password = '$pass'. If an attacker enters the username ' OR '1'='1 and leaves the password blank, the query becomes SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''. The OR '1'='1' clause is always true, so the WHERE filter no longer restricts anything and the attacker can log in without valid credentials.
More advanced techniques include UNION-based injection to pull data from other tables, blind injection that infers data one true/false answer at a time, and time-based blind injection that uses deliberate delays when no output is visible. In stacked-query environments an attacker may even append a second statement such as ; DROP TABLE users.
Real-world impact
SQL injection has driven some of the largest breaches on record because a single flawed query can expose an entire database. It consistently appears in the OWASP Top 10 under the Injection category.
- Authentication bypass: logging in as any user, including administrators.
- Data theft: dumping entire tables of credentials, payment data, or PII.
- Data tampering or destruction: modifying balances or deleting records.
- Lateral movement: reading database files or, with sufficient privileges, executing operating-system commands.
How to prevent it
The primary defense is parameterized queries, also called prepared statements. With parameters, the SQL command structure is sent to the database first and the user data is bound separately, so input can never be interpreted as code no matter what characters it contains.
- Use parameterized queries / prepared statements for every dynamic query.
- Prefer well-reviewed ORMs or query builders that parameterize by default, but stay alert to raw-query escape hatches.
- Apply allowlist input validation, especially for elements that cannot be parameterized such as table or column names.
- Enforce least privilege on the database account so a successful injection cannot drop tables or read everything.
- Escaping is a weak last resort; never rely on it instead of parameterization.
Keep exploring
- CWE-89: SQL InjectionThe MITRE weakness entry SQL injection maps to.
- What is insecure deserialization?Another input-handling flaw that leads to code execution.
- What is remote code execution?Where severe SQL injection can ultimately lead.
- Browse the CWE directoryExplore the full catalog of weakness types.
- What is command injection?Running OS commands through unsanitized input.
Frequently asked questions
- What is SQL injection in simple terms?
- It is when an attacker types special characters into an input field that the application pastes straight into a database query, tricking the database into running commands the developer never intended.
- What is the best way to prevent SQL injection?
- Use parameterized queries (prepared statements) everywhere. They keep the query structure separate from user-supplied data, so input can never be executed as part of the SQL command.
- Does input escaping stop SQL injection?
- Escaping can reduce risk but is fragile and easy to get wrong across different databases and contexts. Parameterized queries are the reliable fix; treat escaping only as a fallback where parameters are impossible.
- Which CWE covers SQL injection?
- SQL injection is CWE-89, Improper Neutralization of Special Elements used in an SQL Command. It is a child of the broader injection weakness CWE-74.