By 
SQL injection has been documented since the late 1990s. Frameworks have evolved. ORMs are everywhere. Parameterised queries are standard practice in any reputable computer science course. And yet, SQL injection still ranks among the most damaging issues found during security assessments, year after year. The reason is simpler than the persistence of the bug suggests: legacy code never goes away, and developers under pressure cut the same corners their predecessors did.
How the Bug Survives Modern Frameworks
Most modern web frameworks default to parameterised queries when used through their standard data access patterns. Where injection still appears, it appears in raw SQL, in stored procedures that build dynamic queries, in ORMs used unsafely with string concatenation, and in JavaScript backends that pass user input straight into NoSQL queries without thinking. The framework cannot protect code that bypasses it. web application penetration testing that focuses on the data access layer specifically catches these cases that scanners frequently miss because the patterns vary so widely between projects.
Blind Injection Hides in Plain Sight
Modern applications rarely return raw database errors to users, which makes classic in-band SQL injection harder to detect through casual testing. Blind injection through timing or boolean responses, on the other hand, remains common. The application returns a generic page in both cases, but the time it takes to respond, or some subtle change in content, reveals whether the injected condition was true. Skilled testers automate the detection of these patterns and confirm exploitation through controlled queries that reveal data without ever generating a visible error.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: I find SQL injection in roughly a third of the web applications I assess, often in code paths the developers told me had no database interaction at all. The bugs hide in admin panels, search features, reporting endpoints, and anywhere a developer thought the input was already validated by something further up the stack.
Why Scanners Miss It Sometimes
Automated scanners hit straightforward injection cases reliably. They struggle with second-order injection, where the payload is stored cleanly and triggers on a later read by a different component. They also miss injections that depend on multi-step workflows, where a series of legitimate-looking requests sets up the conditions for a final exploitable query. Manual testing fills these gaps. Periodic vulnerability scanning services catches the simpler cases between assessments and frees up tester time for the harder bugs that genuinely need a human to find.
The Real-World Impact
Successful SQL injection still leads to data exfiltration on a serious scale. Beyond reading data, attackers can often write to the database, create new accounts, escalate privileges through application logic, and in some configurations execute commands on the underlying server through database functions. The blast radius scales with the database engine, the user account it runs as, and the network position it occupies, and the worst-case scenarios remain alarmingly bad.
Practical Defences That Work
Use parameterised queries everywhere, without exceptions for that one tricky case the team thinks needs concatenation. Validate input at the boundary of the application as well as before the query. Apply the principle of least privilege to database accounts so that even successful injection has limited reach. Log database errors centrally and alert on patterns that look like exploitation. And test specifically for SQL injection during every assessment, because despite all the progress made over the decades, the bug stubbornly refuses to die.
Comments