Scanners detect blind SQL injection by asking the database yes or no questions and watching for a side effect: a different page for true and false, a deliberate delay, or a call to another channel. They infer a flaw from behavior, since no query output or error text is shown.
What makes it blind
With ordinary SQL injection, the application may print database errors or query results, which makes the flaw easy to see. OWASP describes blind SQL injection as the same flaw where the database does not output data to the page. The attacker gets answers by asking true or false questions and reading the application's response. It is often found where the app shows generic error messages but the vulnerable code was never fixed.
Hiding errors is therefore not a defense. It only changes how the flaw is observed.
The three signals scanners use
The OWASP Web Security Testing Guide lists the techniques used against SQL injection. Three apply to blind cases.
| Technique | How it works | What the scanner watches |
|---|---|---|
| Boolean | Inject a condition that is true, then one that is false | Whether the two responses differ in content, length or status |
| Time delay | Inject a database command that sleeps if a condition holds | Whether response time jumps by the expected amount |
| Out-of-band | Make the database send data over a different channel, such as an HTTP request | Whether a listener the scanner controls receives a call |
The OWASP page gives a simple content-based example. A request for an item by ID is repeated with a condition that is always false, then one that is always true. If the true page differs from the false page, the tester can tell when the injected query evaluates true.
Time-based testing relies on the database pausing before returning results. The same page notes that using different date and time functions can also hint at which database engine is behind the app, since MySQL, MSSQL and Oracle use different functions.
Where scanners struggle
- Noisy networks. Timing checks need a baseline. A slow or busy server can look like a delay, so good tools repeat a test and compare against normal response times.
- Dynamic pages. If a page changes on every load (ads, timestamps, tokens), a boolean comparison needs to ignore the changing parts.
- Second-order flaws. Input saved now and used in a query later does not show up in the next response. See second-order SQL injection for why this is hard to confirm safely.
- Blocked outbound traffic. Out-of-band checks fail when the database cannot make outbound calls, even if it is vulnerable. A missing callback is not proof of safety.
- Rate limits and web filters. Probing can be throttled or blocked part way through, producing partial results.
What to do with a result
Treat a timing or boolean finding as strong evidence, then confirm it by hand in a test environment, and fix the cause. Parameterized queries are the fix. Hiding errors, trimming characters or relying on a filter does not remove the flaw. If you need background, read what prepared statements cannot bind.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each finding records the request that triggered it.
Quick check
Does a generic error page protect me from blind SQL injection?
No. Generic errors only hide one signal. Attackers and scanners can still use content differences, timing or out-of-band calls.
If a scan finds no blind SQL injection, am I safe?
Not automatically. Delayed use of stored input, blocked outbound traffic and unreachable pages can all hide a flaw from a scan.
If you want to see where your project stands on dependencies, Safeguard has a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
