SQL injection abuses unsafely handled application input to alter a database query. An attacker supplies SQL-shaped data where an API expects an ordinary filter or other parameter. section 6.3 section 9.4
The failure occurs when user-controlled strings become part of a query without parameterization. An injected condition can disable filters and constraints, expose other users’ records, or produce unexpected behavior. section 6.3 section 9.4
A vulnerable product filter
A normal request might use `GET /products?filter=toasters`. An attacker instead sends `GET /products?filter=' OR 1=1; --`. Without parameterized queries, the injected condition can disable the intended filter. A delay-oriented payload such as `GET /products?filter=' AND 3133=(SELECT 3133 FROM PG_SLEEP(10))--` can consume database connection-pool resources when sent concurrently. section 6.3
Reduce the attack surface with layered controls:
- Parameterize every database query instead of concatenating request values into SQL. section 1.2.2
- Constrain inputs at the API boundary: use enumerations for values such as `sortBy=price`, `review`, or `name`. section 6.3
- Validate and sanitize all input regardless of origin, use established data-transfer patterns, and test handling with fuzz tools. section 1.2.2
- Use a WAF as additional protection, but do not rely on cleanup rules because attackers may bypass them. section 9.4
Figure 6.8 Unconstrained string parameters allow threat actors to send SQL injection attacks to our servers. In this example, a threat actor disables filters and constraints in our query by setting the filter query parameter to ' OR 1=1; --.
Shows how an unconstrained filter parameter carries an injection that disables query filters and constraints. section 6.3
