A code review of a cloud-hosted order service finds SQL statements built by concatenating user-supplied search terms directly into query strings. Which remediation best addresses the root cause, consistent with OWASP ASVS and SAFECode secure coding guidance?

SQL injection occurs when untrusted input is concatenated into a query so that the database parser treats part of the input as SQL syntax. The root-cause fix, required by secure coding guidance such as OWASP ASVS and SAFECode, is to use parameterized queries or prepared statements, where the query structure is fixed in code and user input is passed separately as bound parameters. The database then treats the input strictly as a value, whatever characters it contains. Input validation remains good defense in depth, but it is not the primary control. A web application firewall can block many known injection patterns and is useful as a compensating control, yet it is outside the code, can be bypassed with encodings and novel payloads, and leaves the vulnerable query in place. Escaping single quotes with a custom routine is a fragile, hand-built filter; character sets, numeric contexts and alternative syntax routinely defeat ad hoc escaping, which is why guidance discourages it. Restricting the database account to read-only limits the damage of some attacks, but injection can still read every table the account can see, which is often the main goal. Exam caveat: least privilege for the database account should accompany the fix, not replace it. Operational check: add a static analysis rule that flags string-built queries, confirm the build fails on new findings, and retest the endpoint with injection payloads.