Detecting SQL Injection: What Your Security Scanner Should Check in 2026

1. Why SQL Injection Still Matters in 2026

SQL injection was first documented in 1998. Twenty-eight years later, it remains the single most exploited injection flaw in web applications. Here's why:

• Legacy code is everywhere. Applications built before parameterized queries became standard practice are still running in production. Many have never been refactored.
• ORM misuse creates new injection points. Developers assume their ORM handles sanitization, then use raw query methods (.raw(), .execute(), .extra()) that bypass it entirely.
• The attack surface has expanded. Classic SQL injection now coexists with NoSQL injection (MongoDB $where), GraphQL injection, and ORM-layer injection. A03 covers all of them.
• Scanners miss it. Many security scanners only test GET parameters with a single quote and call it done. They miss POST body parameters, JSON payloads, HTTP headers, and cookie values — all of which can be injectable.

The impact of successful SQLi hasn't changed either: full database extraction, authentication bypass, data modification, and in some configurations, remote code execution via xp_cmdshell (MSSQL) or LOAD_FILE (MySQL).

2. Error-Based Detection: When the Database Talks Back

Error-based SQL injection is the easiest to detect and the most common finding in automated scans. It works when the application returns database error messages in the HTTP response.

The detection logic is straightforward:

1. Inject a payload that breaks the SQL syntax (e.g., a single quote ')
2. Read the HTTP response body
3. Search for database-specific error strings

If the response contains You have an error in your SQL syntax, you've confirmed two things: the parameter is injectable, and the backend is MySQL. That's enough for a HIGH severity finding.

Here's what error-based detection looks like in practice. A vulnerable search endpoint:

GET /search?q=test' HTTP/1.1

Returns:

You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the
right syntax to use near ''' at line 1

The application is concatenating the q parameter directly into a SQL query. The single quote breaks the string literal, and MySQL's error message leaks through to the response. This is a textbook A03 finding.

The key insight for scanner builders: you need error patterns for every major database, not just MySQL. A scanner that only checks for MySQL errors will miss PostgreSQL, MSSQL, and SQLite injection on the same endpoint.

3. Boolean-Based Detection: When Errors Are Suppressed

Production applications often suppress error messages — custom error pages, generic 500 responses, or error logging without display. Error-based detection fails here. Boolean-based detection fills the gap.

The technique:

1. Fetch the page with the original parameter value (baseline)
2. Inject a tautology payload: 1 OR 1=1 (always true)
3. Inject a contradiction payload: 1 AND 1=2 (always false)
4. Compare response lengths against the baseline

If the true payload returns a response similar to the baseline but the false payload returns a significantly different response (or vice versa), the parameter is injectable. The application is evaluating the injected SQL and changing its behavior based on the result.

SecurityClaw's sqli-probe uses a 50% response length threshold: if the injected response differs from the baseline by more than 50% of the baseline length, it flags a MEDIUM severity boolean-based finding. This threshold balances sensitivity against false positives — minor content variations (timestamps, CSRF tokens) won't trigger it, but a query that returns 0 rows instead of 100 will.

Boolean-based findings are rated MEDIUM rather than HIGH because the detection is inferential — you're measuring a side effect rather than reading a confirmed error. Manual verification is recommended before reporting to the application owner.

4. The Payloads That Matter

Not all SQLi payloads are equal. A good scanner tests a focused set that covers the major injection patterns without generating excessive traffic. Here are the payloads that matter and why:

These 7 payloads cover the major injection patterns: syntax breaking, escape testing, tautology bypass, statement stacking, UNION extraction, and alternate delimiters. A scanner that tests all 7 against every parameter will catch the vast majority of injectable endpoints.

5. Database Fingerprinting via Error Signatures

When error-based detection succeeds, the error message itself reveals which database is running. This is valuable intelligence for both the scanner (to refine follow-up payloads) and the security team (to assess impact).

Here are the error signatures that identify each major database:

A scanner should check for all of these patterns, not just one database. Many web applications use different databases for different services — the main app might run PostgreSQL while an internal admin panel uses SQLite. Testing only for MySQL errors would miss both.

SecurityClaw's sqli-probe checks 14 distinct error patterns across all 4 databases plus generic SQL error strings. When a match is found, the finding includes the identified database type, which helps the security team prioritize remediation — a MySQL injection on a customer-facing endpoint is more urgent than a SQLite injection on an internal tool.

6. How to Fix SQL Injection

Every SQLi vulnerability has the same root cause: user input is concatenated into a SQL query string instead of being passed as a parameter. The fix is always the same pattern — parameterized queries — but the implementation varies by language and framework.

The Vulnerable Pattern (Don't Do This)

# Python — VULNERABLE
cursor.execute("SELECT * FROM users WHERE name = '" + username + "'")

# PHP — VULNERABLE
$result = mysqli_query($conn, "SELECT * FROM users WHERE name = '$username'");

# Java — VULNERABLE
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE name = '" + username + "'");

The Fixed Pattern (Do This)

# Python — SAFE (parameterized)
cursor.execute("SELECT * FROM users WHERE name = %s", (username,))

# PHP — SAFE (prepared statement)
$stmt = $conn->prepare("SELECT * FROM users WHERE name = ?");
$stmt->bind_param("s", $username);
$stmt->execute();

# Java — SAFE (PreparedStatement)
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
stmt.setString(1, username);
ResultSet rs = stmt.executeQuery();

Defense in Depth

Parameterized queries are the primary fix, but defense in depth means layering additional protections:

• Input validation. Whitelist expected input types. If a parameter should be a numeric ID, reject anything that isn't a number before it reaches the query layer.
• ORM with parameterization. Use an ORM (SQLAlchemy, Hibernate, Eloquent) that parameterizes queries by default. But never use the ORM's raw query escape hatch (.raw(), .extra()) with user input.
• Least-privilege database accounts. The application's database user should only have SELECT, INSERT, UPDATE, DELETE on the tables it needs. Never use the root/admin database account. This limits the damage if injection succeeds.
• Suppress error messages. Never display raw database errors to users. Log them server-side and return a generic error page. This doesn't prevent injection, but it prevents error-based data extraction.
• Web Application Firewall (WAF). A WAF can block common SQLi payloads at the network edge. It's not a substitute for fixing the code, but it buys time while remediation is in progress.

7. Scanner Checklist: What Your Tool Should Cover

If you're evaluating a security scanner's SQL injection detection capabilities, here's what to look for:

Bottom Line

SQL injection is a solved problem in theory — parameterized queries have existed for decades. In practice, it remains the most exploited injection flaw because legacy code persists, ORMs get misused, and scanners don't test thoroughly enough.

A proper SQLi scanner needs both error-based and boolean-based detection, multiple payload types covering different injection contexts, error signatures for every major database, and the discipline to test every parameter on every endpoint. SecurityClaw's sqli-probe skill implements exactly this — 7 payloads, 14 error patterns, 4 database signatures, and boolean-based fallback with a calibrated threshold.

If your current scanner only sends a single quote to GET parameters and calls it done, you're missing injectable endpoints. The fix is straightforward: parameterized queries everywhere, input validation as a second layer, least-privilege database accounts, and suppressed error messages. None of this is new. The challenge is doing it consistently across every query in every application.