SQL injection was first documented in 1998. Nearly three decades later, it remains one of the most common critical vulnerabilities we find. The question is simple. Why.
The answer is not that developers do not know about SQL injection. Every computer science program teaches it. Every security training mentions it. The problem is more subtle than awareness.
First, ORMs give developers a false sense of security. Most of the time, an ORM handles parameterization correctly. But there are edge cases. Raw queries for complex joins. Dynamic table or column names. Custom sorting parameters. These are the places where developers drop down to raw SQL and forget to parameterize.
Second, legacy code accumulates. A modern application might have a perfectly secure data access layer. But somewhere in the codebase there is a ten year old admin endpoint that nobody has touched. It still uses string concatenation for queries because it was written before the team adopted an ORM.
Third, second-order SQL injection is widely misunderstood. Data gets stored safely through a parameterized insert. Then it gets retrieved and used in a different query without parameterization. The input was validated at entry point A, but it is exploited at exit point B. Most developers do not think about this flow.
Our agents find SQL injection in applications that have passed previous security audits. The reason is simple. They test every parameter, in every endpoint, with context-aware payloads. They do not just try a single quote and move on. They test time-based blind injection, error-based injection, UNION-based injection, and stacked queries. They test each one with multiple encoding and evasion techniques.
The fix is not complicated. Use parameterized queries everywhere. No exceptions. Audit your codebase for raw SQL. Pay special attention to admin panels, reporting endpoints, and anything that accepts dynamic column or table names. And test regularly, because new code means new potential injection points.