SQL Injection Is Not Dead

SQL injection was first documented in 1998. Almost three decades later, it still appears in bug bounty programs, CVE advisories, and real-world breaches. Why does it persist?

Why SQLi Still Happens

Legacy code

Many applications are built on top of codebases that predate modern ORM frameworks. Raw SQL queries with string concatenation are still common, especially in internal tools and admin panels that "nobody external will ever see."

ORM misuse

Even with ORMs, developers reach for raw queries when the ORM cannot express a complex operation. A single raw query with unsanitized input is all it takes.

Second-order injection

Data stored safely in one context gets used unsafely in another. A username might be properly escaped on registration but concatenated into a query in an admin reporting dashboard.

What Modern SQLi Looks Like

Classic error-based injection — where the database error message appears in the response — is less common now. Modern SQLi more often involves:

Blind boolean-based

The attacker infers data by asking true/false questions. If the page renders normally for a true condition and differently for false, each bit of data can be extracted.

Time-based

When there is no visible difference in response content, the attacker uses database sleep functions. A delayed response confirms the condition was true.

Out-of-band

The attacker uses database features (like DNS lookups or HTTP requests) to exfiltrate data through a channel they control, bypassing response-based detection entirely.

How Detection Works

Automated detection sends payloads that are designed to produce observable side effects: error messages, timing differences, or behavioral changes. The scanner establishes a baseline response, sends each payload, and compares the result.

The challenge is false positives. A slow response might be server load, not a sleep injection. A different page might be caching, not boolean injection. Good scanners use multiple confirmation payloads and statistical analysis to separate real vulnerabilities from noise.

Takeaway

SQLi persists because it only takes one unparameterized query in an entire application. Automated scanning catches the straightforward cases. For everything else, understanding how injection works — and where developers cut corners — is still essential.