Security
SQL Injection
Injecting malicious SQL through unsanitised input so attacker text becomes executable query — dumping or destroying the database. The definitive fix is parameterised queries or prepared statements that separate code from data; never concatenate input into SQL. An ORM helps but is no guarantee once you drop to raw queries.
Purpose
SQL injection turns user input into executable query: concatenate ' OR '1'='1 into a WHERE clause and authentication collapses; worse payloads dump tables or delete them. It has been a top vulnerability for twenty-five years because string-building queries remains temptingly easy.
When to Use It
The risk lives wherever input meets a query: login forms, search boxes, filters, sort parameters, anything reading URL or form values into SQL. The same injection class extends to NoSQL queries, LDAP and OS commands — any interpreter fed unsanitised strings.
Trade-offs
The fix is cheap and absolute, which makes remaining vulnerabilities inexcusable to reviewers and auditors. ORMs prevent it by default but not once you drop to raw SQL or interpolate identifiers (table or column names) that parameters cannot cover — those need allow-lists.
Implementation
Use parameterised queries/prepared statements everywhere — the query text and the data travel separately, so input can never become syntax. Allow-list dynamic identifiers, run the app's database user with least privilege, and turn detailed SQL errors off in production so failures do not leak schema.