SQL injection occurs when data supplied from outside a trusted boundary becomes part of SQL syntax. The database then interprets some of that data as a command rather than as a value. The flaw can affect reads and writes, and it can appear anywhere the application constructs a query dynamically.
Where SQL injection enters generated code
Forms and public API parameters are familiar sources, but they are not the only ones. Administrative filters, report builders, imported files, webhook fields, stored values, and job parameters can all reach a database later. A value may pass through several functions before it reaches the query that makes it dangerous.
An audit of vibe-coded software traces database access across the full attack surface. Generated code may use safe query helpers in one feature and assemble raw SQL in another. Similar screens do not guarantee similar database handling.
| Query pattern | Audit question | Safer boundary |
|---|---|---|
| Record lookup | Is the identifier bound as a value? | Parameterized query |
| Search and filter | Can input become an operator or clause? | Allow-listed fields and operators |
| Sorting | Can a column or direction be supplied freely? | Fixed mapping to known identifiers |
| Bulk import | Do stored values reach later queries? | Validation plus parameter binding |
| Reporting | Does a template concatenate fragments? | Reviewed query builder or fixed query |
Validation is not query separation
Input validation can reject values that do not meet the application's contract. It does not replace parameter binding. A valid customer name can still contain punctuation, and a numeric check on one route does not protect a different query path.
The key distinction is between SQL structure and data. Values should travel through the database driver's parameter mechanism. Identifiers such as approved sort columns usually require an explicit mapping because they cannot always be passed as ordinary values. Escaping input by hand is difficult to verify consistently and depends on database and encoding rules.
What the audit checks
Reviewers follow every path that creates or executes SQL:
- Raw query calls: Find string interpolation, concatenation, and template fragments.
- Query builders: Confirm that dynamic operators, identifiers, and clauses use constrained inputs.
- Indirect flows: Trace data stored first and used in a command later.
- Privileges: Check whether the application database identity can perform more operations than the feature needs.
- Failure behaviour: Ensure database errors do not expose query text, schema details, or stored values.
Evidence that the boundary holds
Code review establishes how commands are built. Tests then exercise the exact data path with values that would change a command if separation failed. The expected result is normal data handling or a controlled rejection, with no unintended read, write, or error disclosure.
One safe query does not prove a safe application. The audit records the helper, convention, or data-access layer that keeps the boundary consistent, then identifies every exception. This is part of the review discipline required when AI-generated code moves into production.
