SQL injection testing, proven
SQL injection (SQLi) — what it is, why a signature scanner misses the cases that matter, and how SuperPentest proves it with a controlled test, clean-session reproduction and hash-chained evidence mapped to A03: Injection.
SQL injection is a vulnerability class scanners only partly reach — here is what it is, why that is, and how SuperPentest proves it on your app.
What SQL injection is
SQL injection happens when untrusted input is concatenated into a database query, letting an attacker change the query’s meaning — reading data they should not see, bypassing authentication, or in some cases executing commands. It remains one of the most damaging web vulnerabilities precisely because a single reachable parameter can expose an entire database.
What it looks like
A product-search box drops its query straight into a SQL statement. Submitting ' UNION SELECT email, password_hash FROM users-- returns the user table on the results page. The blind variant needs no visible output at all: ' AND sleep(5)-- that makes the page hang for five seconds confirms it, and data is then read one character at a time.
Why a scanner misses it
A scanner catches the obvious reflected cases, but misses blind and time-based injection behind authentication, second-order injection where the payload fires later, and injection reachable only after a specific multi-step workflow. It also raises false positives on inputs that look injectable but are parameterised downstream.
How SuperPentest proves it
SuperPentest treats SQL injection the way an attacker does, in four steps: it understands the business rule the feature is meant to enforce, runs a controlled test against it, then reproduces any candidate from a clean session — a fresh login with no leftover state — and finally records the impact with hash-chained request/response evidence mapped to the control it breaks. Nothing is reported as a finding until that clean-session reproduction succeeds; a candidate is not a finding.
- Understand — map the feature and the rule it should enforce.
- Controlled test — exercise the class safely, within the authorized scope.
- Clean-session reproduction — break in again from a fresh session to rule out flukes and stale state.
- Impact + evidence — hash-chained request/response, mapped to A03: Injection and your compliance controls.
Where it fits in coverage
SQL injection is one of the 35 vulnerability classes the engine tests every run, driven through 40+ specialist tools orchestrating 13 industry-standard open-source scanners. See the full coverage map or the 35 classes explained.
Related vulnerability classes
XSS testing · SSTI testing · command injection testing · DOM XSS testing.
FAQ
Can a scanner find SQL injection?
A scanner finds some cases, but misses the ones that matter — behind authentication, blind variants, or anything needing a multi-step workflow — and raises false positives on the rest. SuperPentest verifies each candidate before it counts.
How do I know a reported SQL injection finding is real?
Every finding is reproduced from a clean session with hash-chained request/response evidence you can replay. If a run cannot complete the checks, it is stamped degraded coverage rather than passed as clean. See how findings are verified →
Test your app for SQL injection. Book a demo or request an evaluation account. See the sample report.