A utilities lookup API builds database queries by concatenating citizen-supplied IDs into SQL strings. Which change is the primary SQL injection mitigation?

SQL injection thrives when untrusted citizen IDs are concatenated into SQL strings. The primary mitigation for the utilities lookup API is to use bound parameters or an ORM equivalent so the database distinguishes code from data. Parameter binding stops crafted IDs from altering WHERE logic, UNION stacks, or administrative statements while still allowing legitimate lookups.

Adding a CSRF token to every SELECT fails threat matching: CSRF tokens protect browser state changes, not SQL construction on the server. HTML-encoding the query string before sending it to the database fails because HTML encoding is an output-to-browser control, not a SQL wire encoding. Relying on a WAF signature alone while keeping string-built WHERE clauses fails defense-in-depth; WAFs miss novel payloads and still leave the root concatenation bug in municipal code.

Exam caveat: stored procedures are safe only if they still bind inputs—string-building inside a procedure recreates SQLi. Escape-only approaches are weaker than parameters and are easy to get wrong across dialects.

Operational check: run a classic ' OR '1'='1 probe against the lookup and confirm the parameterized path returns a normal empty or authorized result rather than dumping rows, with query logs showing bind variables instead of interpolated SQL.