It occurs when an application builds database statements by combining command text with attacker-influenced values without preserving a reliable boundary between code and data. A successful attack may read or change data, bypass application checks, or invoke database capabilities available to the application account.
The primary defense is to keep query structure fixed and pass values through parameterized interfaces. Input validation can enforce business expectations, but it does not replace parameterization; database permissions should also limit consequences if another control fails.
Key points
Safe query constructionUse prepared statements or correctly parameterized database interfaces throughout every data-access path, including background jobs, administrative features, imported data, and indirect inputs.
Dynamic query elementsParameters often cannot represent table names, column names, or sort directions. Map such choices to a fixed allowlist or redesign the query rather than inserting untrusted text.
Consequence reductionGive application identities only necessary database privileges, separate roles where practical, protect connection credentials, avoid unnecessary database capabilities, and monitor abnormal query behavior.
Important limitationEscaping, stored procedures, object-relational mapping, input validation, or a web application firewall does not automatically prevent SQL injection; safety depends on how each query is ultimately constructed and executed.