SQL injection refuses to fade quietly into the history books. Twenty five years after the technique first hit security advisories, it still appears in the OWASP Top Ten and still surfaces in nearly every web application engagement we run. The reason is simple. Developers under deadline pressure reach for the patterns they know, and many of those patterns were learned long before attackers discovered how to bend them.
Why Modern SQLi Looks Different
Single quote injection still works against ageing systems, but attackers have moved on. Today the payloads target second order vulnerabilities, where unsafe input gets stored cleanly and then concatenated dangerously somewhere else in the stack. Blind techniques drip information out through timing channels. Stored procedures, JSON functions and database specific syntax all get abused in ways that filters built five years ago never anticipated. A serious best pen testing company will examine every one of these surfaces because automated scanners routinely miss them.
Parameterised Queries Are Not Optional
Every modern database driver supports parameterised queries. The claim that an ORM handles the problem completely falls apart the moment a developer drops to raw SQL for a performance win, and every team has that one query somewhere in the codebase. Make parameterisation the default in your coding standards and treat raw string concatenation as a code review failure. This single discipline removes the majority of injection paths before they ever reach production.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
The teams that handle SQL injection well treat it as a code review problem, not a scanner problem. Tooling catches the obvious cases. The dangerous ones tend to be queries built dynamically from a handful of optional filters that nobody thought to test in combination.
Where The Tooling Helps
Static analysis catches roughly half of the unsafe patterns when configured properly. Runtime application self-protection tools watch live traffic for injection attempts and have come a long way in the last few years. Database activity monitoring flags unusual query patterns at the storage layer, well downstream of the application. None of these tools replaces good coding practice, and none of them works as a one-time deployment. Pick one or two layers, integrate them properly into your operational practice and resist the temptation to add five more on top. The teams that get value from SQL injection defences pick a handful of controls and run them well, rather than buying a stack of tools that nobody has time to tune. Layering is good. Layering badly is worse than picking fewer layers and doing those properly. The shift to managed databases removes a chunk of the surface area but does not solve the application logic problem, because the unsafe query is still constructed in your code regardless of where the database runs.
Defence in Depth Still Matters
Parameterised queries form the foundation but they are not the whole picture. Least privilege database accounts, separate read and write users, sensible error handling and proper logging close the windows attackers rely on to exfiltrate data once they find a way in. Pair this with regular web application pen testing and you have a layered approach that survives the inevitable lapse in any single control.
If you are unsure where your own applications sit on this curve, a focused assessment is the fastest way to find out before someone less friendly does. The teams that take this seriously rarely make the news for the wrong reasons. The discipline pays back quietly every month it stays in place. Web application security is a discipline that rewards patient investment. The teams that treat it as ongoing work consistently outperform the ones that treat it as a project with an end date.
