Direct answer
SQL injection happens when untrusted input changes the structure or meaning of a database query. Assessment should connect a controllable input to query construction or reproducible query behavior, rather than treating a database error as proof.
Review the data and query boundary
Parameterized queries separate bound data from SQL structure. Review query-building code around search, filtering, sorting, and reporting. Dynamic table or column choices require deliberate allowed values because they are not ordinary data parameters.
Reference: OWASP SQL Injection Prevention Cheat Sheet.
Choose a bounded assessment path
A staging search endpoint with seeded records is a better place to investigate a candidate than a production checkout. Record normal responses and latency before introducing controlled variations. Agree on a request budget and avoid tests that modify or extract unrelated data.
- Use fixtures with a known expected result set.
- Identify the parameter and route independently of the error message.
- Obtain separate approval for expensive or state-changing checks.
Rule out ordinary failures
A malformed request can trigger validation, caching, a gateway timeout, or a database exception without changing query semantics. Repeat the control and candidate conditions under similar load. If only timing suggests a problem, retain the variability and alternative explanations in the report.
- Record response differences across several controlled comparisons.
- Check whether the same error occurs with unrelated invalid input.
- Use code review or application logs when safely available.
Repair and retest the affected query
Replace unsafe concatenation with the database library's parameter binding. Retest the original candidate and the intended search or filter behavior. Review adjacent query builders because a shared helper can repeat the defect across several endpoints.
Reference: OWASP SQL Injection Prevention Cheat Sheet.
Assessment limits
A generic SQL error is a candidate signal. Timing evidence is particularly sensitive to network and server noise. Tests must respect data and availability limits; destructive queries and large data extraction are unnecessary for most remediation decisions.
Frequently asked questions
Does input validation alone prevent SQL injection?
Validation helps enforce business rules, but query construction still needs safe parameter binding. Fields that legitimately accept punctuation must remain data rather than becoming query syntax.
Does every database exception indicate injection?
No. An exception may reveal error handling or validation problems. Establish how the input affects the query before labeling the finding SQL injection.
Can an ORM introduce SQL injection?
An ORM does not make raw SQL fragments safe automatically. Review escape hatches, string-built conditions, and dynamic sorting alongside ordinary ORM queries.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.