SQL injection occurs when an application builds a database query by pasting user input directly into a SQL string. OWASP describes the attack as “insertion or ‘injection’ of a SQL query via the input data from the client to the application” (owasp.org/www-community/attacks/SQL_Injection). Because the input is concatenated into the query text rather than kept separate from it, a crafted value can change what the query means, turning ordinary data into executable SQL commands.
The CWE database catalogs this as CWE-89, “Improper Neutralization of Special Elements used in an SQL Command.” Its description is precise about the root cause: without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated query can cause those inputs to be interpreted as SQL instead of ordinary user data (cwe.mitre.org/data/definitions/89.html). A successful injection can let an attacker read data they should not see, modify or delete records, bypass authentication, or in some configurations run commands on the host.
The fix is to stop mixing code and data. OWASP names parameterized queries, also called prepared statements, as the primary defense: the query structure is fixed in advance with placeholders, and user values are passed separately so the database never treats them as syntax. OWASP explicitly warns that weaker measures, such as escaping characters or relying on stored procedures alone, are insufficient on their own.
SQL injection has stayed near the top of the OWASP list for more than two decades because the mistake is easy to make and the payoff for attackers is large. It is one specific case of the broader code-injection problem, where untrusted input is interpreted as commands by a downstream interpreter rather than handled as inert data.