PENTESYS POINT OF VIEW · ENGINEERING · 4 min read
Part of Validate insights →SQL injection prevention and remediation verification
Keep untrusted values separate from query structure and verify the actual database-access paths.
Fix the way queries are constructed, then verify related paths; blocking one suspicious input pattern is not a complete correction.
Identify where query structure is created
Trace the application path from input to the database call, including reports, background work and administrative functions. Determine which values influence a query and whether any are being combined with executable query text. A visible error or a scanner observation is a starting point for investigation, not an explanation of every affected data-access path.
Use parameterised value handling
Use the database library's supported parameter binding for data values rather than constructing executable query text from them. Review the actual call, not merely the presence of an ORM in the project. Raw-query features, stored routines and helper functions can still introduce unsafe construction. Separate concerns so code review can see which parts define the operation and which parts supply data.
Treat dynamic structure separately
Some applications choose identifiers, sort behaviour or optional clauses dynamically. Those choices need a controlled design rather than an assumption that ordinary value parameters cover every part of a query. Prefer fixed query shapes and explicit allowed choices where practical. Review whether the feature requires dynamic structure at all before adding another escaping or filtering layer to a complicated construction process.
Limit the consequence and remove unsafe assumptions
Use the privileges the application actually needs and keep production data and credentials appropriately protected. These measures can reduce consequence but do not replace correcting unsafe query construction. Avoid exposing unnecessary database error detail to users. Consider whether the same query-building pattern is repeated in other modules so the remediation addresses a cause rather than a single failing request.
Verify with controlled evidence
Under explicit authorisation, confirm the affected behaviour has changed and that legitimate queries, unusual data values and relevant error paths still behave as intended. Use test records and agreed methods. Retain the application version, affected operation and result, and add regression coverage around the query boundary. A filter that rejects one observed input is weaker evidence than a reviewed and tested change to how the operation is built.
Turn the analysis into action.
- Trace values and structure to the actual database operation.
- Use supported parameterisation and controlled dynamic choices.
- Review privileges and verify the corrected data-access paths.
Sources and further guidance
Use the essential guide for the wider scope, process and buying context behind this analysis.
Read “Penetration testing: scope, process, costs and what happens after the report” →This current engineering guide replaces the retired legacy topic. Apply the recommendations to the actual application and verify changes within an authorised scope.
