Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To catch the SQL injection bug a quick code review misses, trace every untrusted value through helpers, repositories, ORM calls, and stored procedures to the actual database execution point. Check whether the database receives the value separately as a bind parameter—or whether any layer combines it with SQL text first. A familiar API name, an ORM, or a stored procedure is not proof that the final query is safe.
Why a safe-looking database call can still be vulnerable
SQL injection is a data-flow problem. A request value can pass through several methods that look harmless before a lower layer inserts it into a query string. The review question is not whether the code uses a repository, ORM, or procedure; it is whether untrusted data can change the SQL structure when the database executes it.
OWASP’s Secure Code Review Cheat Sheet tells reviewers to look for “string concatenation in database queries and unsafe query construction.” Its review process also emphasizes identifying entry points and tracing data flow. Start with changed code, then follow relevant callers and callees until you reach the execution boundary.
Recommended Free Tools
How to trace untrusted data to execution
- Find sources. Mark request parameters, form fields, headers, cookies, imported data, and other values that an untrusted party can influence.
- Find database boundaries. Locate database execution APIs, raw SQL methods, ORM query-language calls, and repository abstractions in the changed code and the methods it invokes.
- Follow each value. Track whether a source value is transformed, copied, combined with other data, or passed into a helper. Do not stop at a method named
query,safe,prepared, orrepository. - Inspect the final construction and call. Confirm that values are supplied through the database API’s separate binding mechanism. A placeholder-looking string is not enough if the value is later inserted into that string or the API sends assembled SQL.
- Review the surrounding behavior. Check authorization, error handling, and business logic as well as query construction; a change can introduce security problems beyond injection.
What keeps values separate from SQL syntax
Prepared statements and parameterized queries let the application provide SQL structure separately from data values. The database treats a bound value as data rather than interpreting it as part of the command. OWASP’s Top 10:2025 A05 Injection identifies keeping data separate from commands and queries as the best means of preventing injection.
#1 Best Overall
Safely implemented stored procedures can provide similar protection, but the procedure must preserve that separation. OWASP notes that prepared statements and safely constructed stored procedures are similarly effective against injection; the right choice depends on the implementation context. A procedure that concatenates its parameters into dynamic SQL can undo the protection provided by a parameterized application call.
| Approach | How it handles query structure and values | What reviewers still need to inspect |
|---|---|---|
| Prepared statement or parameterized query | Passes values separately from SQL structure when binding is performed by the database API. | Verify that the API really binds values and that no later layer assembles raw SQL. |
| Stored procedure | Can keep values separate when implemented safely; it can also build dynamic SQL. | Inspect procedure code, dynamic execution, how parameters enter the statement, and the procedure’s permissions. |
| Dynamic identifier or sort selection | Table names, column names, and sort direction are SQL structure and generally cannot be supplied as ordinary bound values. | Prefer fixed code or redesign. If selection is required, map an input enum or other validated choice to a strict set of fixed allowed fragments. |
False assurances to test, not accept
“It uses an ORM”
An ORM does not make every query safe. OWASP’s 2025 injection examples show that concatenating user input into Hibernate Query Language can alter query meaning. Inspect the final query-building method and confirm where values are bound. The same review applies to raw-query escape hatches inside an otherwise ORM-based application.
“The application calls a stored procedure”
Trace into the database-side code. Search procedure definitions and related database code for dynamic execution constructs such as SQL Server EXEC or sp_execute, and Oracle EXECUTE IMMEDIATE. Determine whether untrusted input becomes a value or part of the generated SQL text. A parameterized call at the application boundary does not secure unsafe dynamic SQL inside the procedure.
“We sanitize the input”
Validation can be useful as a secondary control, but it is not a substitute for separating values from query structure. Legitimate text can contain characters that have special meaning in SQL. Use validation for the application’s accepted data rules, and binding to prevent values from being parsed as SQL syntax.
“The client library parameterizes it”
Check what the library actually sends. OWASP warns that some client-side libraries build a query string through concatenation before sending raw SQL. A placeholder in application code is not proof of server-side binding; verify that the value is passed separately at the execution boundary.
When SQL needs a table, column, or sort choice
Bind variables represent data values, not arbitrary SQL structure. If a feature selects a sort column or direction, do not splice an unchecked request value into the statement. Prefer a fixed query or redesign the feature so structure remains static. If a choice is necessary, translate a narrowly defined input option into one of a finite set of hard-coded fragments, then bind ordinary values as parameters.
Keep that mapping close to query construction and make its allowed choices explicit. Review the mapping as part of the security boundary: an allow-list that falls back to the original input, or that accepts arbitrary identifiers, does not constrain query structure.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Use automated testing to extend manual review
Manual review is useful for following context-sensitive flows, complex helper layers, authorization effects, and database-side behavior. It should be combined with automated testing rather than replaced by it. OWASP’s review guidance recommends source review together with automated testing, including fuzzing.
- SAST analyzes source code and can flag suspicious query construction or flows. Review findings in context and inspect paths the tool may not understand.
- DAST exercises a running application and can reveal injection behavior on tested paths. A clean result does not establish that untested paths are safe.
- IAST observes application behavior during execution and can help connect exercised inputs to vulnerable operations. It also depends on the paths and conditions reached during testing.
Use these techniques to focus and broaden review, then resolve findings against the actual code and execution path. OWASP’s Web Security Testing Guide section on testing for SQL injection provides dynamic-testing context. For a verification baseline, ASVS 5.0 requirement V1.2.4 calls for database queries to use parameterized queries, ORMs, entity frameworks, or other protections, including stored procedures.
Quick Recap
A reviewer’s final checklist
- Have you identified untrusted sources and followed them all the way to database execution?
- Are values bound separately by the actual database API, rather than merely placed in a string that resembles a parameterized query?
- Have you inspected raw SQL, ORM query languages, helper methods, and stored procedure implementations?
- Are dynamic identifiers and sort choices fixed or selected through a strict mapping to known fragments?
- Have you considered authorization, error handling, and business logic alongside injection?
- Have automated findings and test results been checked against the code paths they actually analyze or exercise?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
