What Is SQL Injection? How Scanners Detect and Prove SQLi

SQL injection (SQLi) has troubled web applications for more than two decades, and it still works exactly the way it did in the early 2000s: user input reaches a database query without safe handling, and an attacker rewrites the query's logic. Despite parameterized queries being a solved problem in every mainstream language, SQLi consistently appears in the OWASP Top 10 and in real breach reports every single year. In this guide we explain the attack clearly, show the four detection techniques that matter, and show how an automated scanner can find — and prove — SQLi without taking your site down.

What SQL Injection Actually Does

In a vulnerable application, a query is built by gluing strings together:

SELECT * FROM users WHERE email = '[email protected]';

If the email parameter is concatenated without escaping or binding, an attacker can submit a value like ' OR '1'='1 and change the query's meaning entirely. Depending on where the flaw sits and how the database responds, the attacker may be able to log in without a password, dump the entire user table, modify records, or — in the worst cases — read files from the database server and sometimes execute operating-system commands.

The reason SQLi is still rated critical in most severity frameworks is the blast radius: one injectable parameter can expose every row in every table the database account can read.

The Four Detection Techniques

Mature scanners do not rely on a single trick. They layer four complementary techniques, because each one catches cases the others miss.

1. Error-based detection

The scanner sends payloads that intentionally trigger database errors — malformed quotes, type confusion, comments. If the response comes back with a database error message (a MySQL, PostgreSQL, or MSSQL error string), that is a strong signal that input reached the query layer. Verbose errors are themselves a finding, but more importantly they confirm injectability.

2. Boolean-based (differential) detection

The scanner sends a statement that is logically TRUE, then a matching statement that is logically FALSE:

• ... AND 1=1 — page renders normally
• ... AND 1=2 — page changes (different content, different length, different status)

If the two responses reliably differ while the URL stays otherwise identical, the application is evaluating injected logic. Differential confirmation is the backbone of low-false-positive SQLi detection because it compares against a baseline the scanner captured beforehand.

3. Time-based detection

When errors are suppressed and responses look identical, the scanner injects a deliberate delay (for example SLEEP(5) on MySQL or pg_sleep(5) on PostgreSQL) and measures whether the response genuinely takes the expected extra seconds. Time-based SQLi is slower to test and easier to get wrong, so a disciplined scanner uses strict time budgets, repeats the delay to rule out network jitter, and never treats one slow response as proof on its own.

4. UNION-based extraction

If the vulnerable query returns rows to the page, the scanner can attempt a UNION SELECT to append its own query results — for example, pulling the database version banner. A UNION proof is the strongest evidence possible: the scanner demonstrates that it read data the application never intended to show.

Why Proof Matters More Than "Detection"

Anyone can fire 5,000 payloads at a form and flag anything unusual. The hard part — and the part that separates a useful scanner from a noise machine — is confirmation with evidence. Before a finding reaches a report, each claim should be backed by something reproducible: the exact request, the exact response, and a differential comparison against a known-good baseline.

That is why the 2MNY scan engine runs a layered SQLi family rather than a single check:

• SQL Injection (Advanced) — differential engine with strict baseline handling
• Deep SQL Injection Scanner — wider parameter coverage and deeper payload sets
• Ghauri SQLi cross-verification — an independent second engine that re-tests candidates, detection-only
• SQLMap confirmation — the industry-standard tool runs in a budgeted, controlled pass to confirm what the custom engines found
• SQL Injection Proof-of-Exploit — attempts a safe, read-only proof (such as a version banner) so the report can show evidence instead of a suspicion
• NoSQL Injection — the same discipline adapted for MongoDB-style APIs where the injection payload is a document, not a string

Cross-verification is deliberate: a finding that survives two independent engines with a differential baseline is a finding you can act on. A finding that only one noisy heuristic produced gets filtered out before it wastes your time.

What a Good SQLi Report Tells You

A scan report should never just say "SQL injection found." It should tell you:

• Where — the exact URL and parameter
• How — the technique that confirmed it (error-based, boolean, time-based, or UNION)
• Evidence — the request/response pair proving the injection
• Severity with reasoning — a CVSS base score plus why the score was assigned
• How to fix it — parameterized queries (prepared statements) as the primary fix, input validation and least-privilege database accounts as defense in depth

Fixing SQL Injection for Good

The fix is consistent across every stack: never build SQL by concatenation. Use parameterized queries or an ORM that binds values. In PHP, that means PDO prepared statements or Eloquent query bindings; in Node, parameterized pg/mysql2 calls; in Python, DB-API parameters. Then verify with a scanner that proves exploitation — not one that guesses.

Check Your Site in Minutes

You can run a quick SQLi-oriented check on any website you own with the free 2MNY security scan, or see the full list of 232 scanners running in our engine — including the complete injection family. Developers who prefer to self-host can grab our open-source core (200 scanner modules, Apache-2.0) on GitHub.

Related reading: Cross-Site Scripting (XSS) Explained · CVSS Scores Explained · OWASP Top 10 Risks