Prefer a fix that uses parameterized queries (prepared statements). Be wary of one that escapes or sanitizes user input by hand. OWASP lists prepared statements as its first defense and marks escaping all user input as strongly discouraged. Check which one the AI chose before you approve.
What the weakness is
CWE-89 describes SQL injection as building all or part of an SQL command from externally influenced input without neutralizing special elements, so the input can change the intended command. The fix is to keep data and command separate.
What OWASP recommends
The OWASP SQL Injection Prevention Cheat Sheet groups its guidance into primary defenses and additional defenses. The primary ones are prepared statements with parameterized queries, stored procedures built safely, and allow-list input validation. Escaping all user supplied input is listed as strongly discouraged. Least privilege for the database account is an additional defense.
So a good AI suggestion usually looks like this: the query text is fixed, and values are passed as parameters.
# Before: user input is part of the command
cursor.execute("SELECT * FROM orders WHERE id = " + order_id)
# After: the query is fixed and the value is a parameter
cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))
(The placeholder style differs by driver, so confirm yours.)
Red flags in a suggested fix
- A custom escape function. It may handle quotes and miss other cases such as encodings or numeric contexts.
- A blocklist of words. Removing the word DROP does not stop other forms of abuse.
- A fix in one place only. If other queries in the same file concatenate input, the pattern remains.
- Dynamic table or column names passed as parameters. Parameters bind values, not identifiers. For those, OWASP points to allow-list validation of the name against known values.
Review steps
- Find every query the change touches and confirm none builds text from input.
- Check identifiers (table, column, sort order) against an allow-list.
- Add a test that sends a classic injection string and expects it treated as plain data.
- Search the codebase for the same concatenation pattern.
- Check database account permissions. Least privilege limits damage if something slips through.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a code scan reports injection findings by file and line, which gives you the list of places to check for the pattern.
A note on frameworks
Many ORMs parameterize by default but offer raw query escape hatches. If the AI reaches for a raw query helper, read it carefully. The safe path is often simply using the ORM's standard method.
Safeguard runs code and dependency scanning and can open fix pull requests, with autonomous remediation off by default. Whatever opens the pull request, the review steps above still apply.
Quick check
Is input validation enough to stop SQL injection?
Not by itself for free text. OWASP treats allow-list validation as useful, especially for identifiers, alongside parameterized queries.
Do stored procedures make me safe automatically?
No. OWASP lists stored procedures as a defense only when used safely, and has a section on when they can increase risk, so review them like any other code.
Sources
Last reviewed: 19 October 2026.
