SQL injection has been a known, documented vulnerability class since the late 1990s. It has survived two decades of parameterized queries, object-relational mapping (ORM), web application firewalls, and mandatory secure coding training becoming industry standard. We often hear that SQL injection has become obsolete in today’s age, however here at Inspectiv we see it showing up every day across many different applications. We see that about 1 in 3 critical bug bounty findings is SQL injection.
Injection dropped two spots in the OWASP Top 10:2025, moving from #3 to #5. That looks like progress until you read further into the category: 100% of the applications OWASP's contributors tested were checked for some form of injection, and SQL injection alone still accounts for more than 14,000 CVEs. OWASP characterizes it as a low-frequency, high-impact vulnerability, rarer than cross-site scripting's much higher CVE volume, but more consequential when it lands.
So the real question isn't whether SQL injection still happens. It's why a vulnerability class this well understood, with a fix this well documented, keeps making it into shipped code.
Most senior practitioners will tell you SQL injection is a solved problem, something from the string-concatenation era before parameterized queries and ORMs became standard. That belief leads many teams to assume their framework handles injection by default, so they stop specifically testing for it, stop specifically training junior engineers on it, and stop specifically reviewing for it in code review.
The assumption is understandable since modern frameworks make the safe path the easy path. But easy isn't automatic, and the gap between the two is where SQL injection still lives: a raw query dropped in for a performance fix, a legacy service that predates the framework migration, an internal admin tool nobody thought to hold to the same standard as the customer-facing app.
Misconceptions aside, the causes of SQL injection are consistent across the available data and with what shows up in testing:
Legacy code and legacy systems: string-concatenated queries written years ago, still running, often outside the scope of newer secure coding standards.
Inconsistent use of parameterized queries: one team enforces prepared statements, another falls back to raw SQL for a “quick” query or a reporting job.
ORM misuse: object-relational mappers prevent injection when used as intended, but developers still drop into raw query methods for complex joins or performance tuning, and that's exactly where the protection disappears.
Under-tested internal surfaces: admin panels, internal APIs, and back-office tools rarely get the same security attention as public-facing applications, even though they often have more direct, less filtered database access.
AI-generated code: Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found SQL injection (CWE-89) in roughly 20% of the AI-generated code it evaluated. While that's actually one of the better scores in the study (cross-site scripting failed 86% of the time), a 1-in-5 failure rate at the volume AI-assisted development now produces code poses a credible risk.
Early SQL injection targeted login forms and search fields with straightforward UNION-based attacks: get the database to return data it wasn't supposed to. Defenses caught up to that pattern years ago, and what persists now is subtler.
Attackers found subtler ways to exploit the same class of flaw: blind and time-based injection, inferring data one true-or-false response at a time instead of reading it directly, and second-order injection, where malicious input is stored safely and only turns dangerous later, when it's pulled into an unsafe query somewhere else in the application. As applications broke apart into APIs and microservices, injection moved with them: a vulnerable query can now sit several services away from the endpoint that received the original input, in an "application" that isn't a single codebase anymore. Most recently, AI-authored injection has entered the mix, where the vulnerability isn't a developer's oversight but a pattern the model reproduced from training data that included plenty of unsafe SQL.
The mechanism hasn't changed: unsanitized input reaching a query. What's changed is where that mechanism hides, and how many places it can now hide in.
As AI-assisted development produces a larger share of production code, expect the raw number of SQL injection instances to track the growth of AI-authored code. But the fundamentals of risk reduction still work. They just have to be applied everywhere, consistently, including the surfaces that don't get the spotlight:
Enforce parameterized queries and prepared statements as a CI gate, not a code review suggestion. If a raw query pattern can merge without a human or automated check catching it, it eventually will merge.
Extend testing scope to internal tools and admin interfaces, not just customer-facing applications. Attackers don't respect that distinction, and a testing program shouldn't either.
Review AI-generated code with the same rigor as human-written code.
Combine intelligent scanning with human validation. Static and dynamic tools are good at flagging known patterns; most are weaker at second-order and logic-layer injection that only shows up when someone actually tries to exploit the application the way an attacker would. Why Validation Matters in Security Testing goes deeper on where that gap tends to show up.
Treat testing as continuous, not a point-in-time event. A codebase that passed a scan last quarter can introduce a new raw query next sprint. Programs built around ongoing testing catch that drift; programs built around an annual assessment find it later, if at all.
Inspectiv's platform combines intelligent automation with expert human researchers who find the second-order and logic-layer injection paths that most tools and AI-assisted code review are likely to miss. Every submission is validated by Inspectiv's triage team before it reaches you, so your engineers spend their time fixing real, confirmed issues.
Ready to see what continuous testing finds that a point-in-time scan doesn't? Get a demo.