Cybersecurity glossary
What is Blind SQL Injection?
Learn what blind SQL injection is, how boolean-based and time-based techniques extract data without visible query results, and how parameterized queries and WAF controls help prevent it.
Definition
Blind SQL injection is a SQL injection technique in which the application does not return query results or database errors in the response, so attackers infer data by observing true/false behavior, timing differences, or other side channels.
Why blind SQL injection matters
Many teams assume SQL injection is only dangerous when the browser displays database rows or verbose SQL errors. Blind SQL injection exists for the opposite case: the application stays quiet, yet the database still evaluates attacker-controlled expressions.
That silence is false comfort. If user input reaches a SQL statement through unsafe concatenation, the database becomes an oracle. Attackers ask tiny questions—“Is the first letter of the admin password hash greater than m?”—and read the answer from page differences, redirects, status codes, or response time. Automation turns those tiny answers into full table dumps.
Blind techniques therefore keep SQL injection relevant in modern apps that already hide stack traces and return generic error pages.
How blind SQL injection works
The root defect is the same as other SQL injection: untrusted input is interpreted as SQL syntax or operators. What changes is the feedback channel.
Find a injectable parameter
Search, filters, sort fields, IDs, cookies, or headers are reflected into SQL without bind parameters.
Confirm boolean control
Payloads such as AND 1=1 versus AND 1=2 produce different observable outcomes even without visible query data.
Choose an inference channel
Use content differences, HTTP status, redirects, or intentional database delays as the yes/no signal.
Enumerate structure
Infer catalog metadata: database engine, schema names, tables, and columns.
Extract values bit by bit
Recover sensitive rows through binary search or character-by-character predicates.
Expand impact
Depending on privileges, continue to file access, authentication bypass, or further compromise.
Boolean-based vs time-based blind SQLi
| Property | Boolean-based | Time-based |
|---|---|---|
| Signal | Different page content, length, status, or redirect for true vs false. | Response is slower when the injected condition is true and a delay runs. |
| Speed | Usually faster than timing methods when a stable content oracle exists. | Slower and noisier; sensitive to network jitter. |
| Stealth | Can look like normal browsing if differences are subtle. | Often easier to notice in logs and APM latency metrics. |
| Typical functions | Conditional filters such as AND/OR predicates on guessed characters. | SLEEP, WAITFOR, pg_sleep, or heavy conditional queries. |
| Best defender signal | Anomalous filter patterns and repeated near-identical requests. | Repeated intentional delays from one client identity or source. |
Out-of-band variants also exist. If the database can make DNS or HTTP requests, an attacker may exfiltrate data through external callbacks. Those are still “blind” from the application’s HTML perspective because the page itself may show nothing useful.
Practical examples
Login or search filter
A product search built as WHERE name LIKE '% + input + %' may never print SQL errors. Sending a condition that is always true returns many results; an always-false condition returns none. That difference is enough to start binary search against sensitive values in other tables when subqueries are allowed.
Numeric identifier
An endpoint such as /order?id=123 may render “not found” versus “forbidden” versus “ok” depending on whether an injected predicate is true. Even without listing columns on screen, those states can encode one bit of information per request.
Quiet APIs
JSON APIs that always return {"status":"error"} can still leak timing. A time-based payload that sleeps only when a guessed character matches creates a measurable channel for extraction.
Impact
Confidential data theft
Account tables, tokens, personal data, and business records can be reconstructed without an obvious data dump in responses.
Authentication bypass
Login queries can be forced true, granting access without valid credentials.
Integrity abuse
If statements are writable, attackers may modify balances, roles, or inventory through inferred success conditions.
Slow but scalable compromise
Tools automate thousands of inference requests, making 'too slow to matter' a weak assumption.
Detection clues
Blind SQL injection rarely announces itself with an ORA- or You have an error in your SQL syntax banner. Look for behavior.
- Review parameters that drive filtering, sorting, pagination, and object lookup for unsafe query construction.
- Alert on repeated requests that differ only by boolean predicates or SLEEP-style expressions.
- Correlate application latency spikes with identical endpoints and shifting payload content.
- Monitor database logs for unusual conditional functions, stacked probes, and catalog enumeration.
- Include blind techniques in DAST and authenticated penetration tests, not only error-based checks.
- Treat generic error pages as insufficient evidence that injection is impossible.
- Watch for outbound DNS or HTTP callbacks from database hosts that should not initiate connections.
- Validate that ORM usage actually parameterizes dynamic order-by, filters, and raw query helpers.
Prevention
The primary fix is the same for all SQL injection classes: never interpolate untrusted input into SQL.
Use parameterized queries, prepared statements, or verified ORM APIs that bind values separately from syntax. Keep identifiers such as column names on allowlists when dynamic sorting is required. Give application database users only the permissions they need—often SELECT/INSERT/UPDATE on specific schemas, never DBA-equivalent roles. Disable unnecessary database features that enable out-of-band exfiltration where operationally feasible.
Defense in depth can include input constraints, WAF rules, and query allowlists, but none of those replace safe statement construction. Hiding errors is good hygiene; it is not remediation.
The practical takeaway
Blind SQL injection proves that SQL injection remains exploitable even when applications refuse to display query results or database errors. Attackers infer data through boolean differences, timing, and other side channels.
If user input can change SQL syntax, silence does not equal safety. Parameterize queries, constrain dynamic identifiers, least-privilege the database account, and test for inference-based techniques explicitly.
Related security terms
SQL Injection (SQLi)
The broader injection class that includes in-band, blind, and out-of-band techniques.
Time-Based SQL Injection
A blind variant that uses intentional delays to infer whether a crafted condition is true.
SQL Injection
Deep dive on exploitation patterns, impact, and remediation for SQL injection flaws.
Web Application Firewall (WAF)
A supporting control that can detect some injection payloads but does not replace secure coding.
Frequently asked questions
What is blind SQL injection in simple terms?
Blind SQL injection happens when an attacker can change a database query through user input, but the app does not show the query output or useful SQL errors. The attacker still learns secrets by asking yes/no questions and watching how the application responds.
How is blind SQL injection different from classic SQL injection?
Classic in-band SQL injection often returns data or database errors directly in the page. Blind SQL injection hides those outputs, so extraction relies on inference through boolean conditions, response differences, timing, or out-of-band channels.
What are the main types of blind SQL injection?
The two common inferential types are boolean-based blind SQL injection, which depends on different application content or status for true versus false conditions, and time-based blind SQL injection, which depends on measurable delays when a condition is true.
Can blind SQL injection still steal data?
Yes. Attackers can enumerate database names, table structures, and row values one bit or one character at a time. It is slower than in-band extraction, but automation makes large-scale theft practical.
Does hiding SQL errors stop SQL injection?
No. Suppressing errors reduces information leakage and can block noisy exploitation, but parameterized queries, least-privilege database accounts, and input handling still remain necessary. Blind techniques exist specifically for quiet applications.
How do you prevent blind SQL injection?
Use parameterized queries or bind variables for all SQL, avoid building statements with string concatenation, validate and constrain inputs, apply least privilege to database roles, and test endpoints that reflect filters, search, sort, and identifiers.
Can a WAF detect blind SQL injection?
A WAF or OWASP CRS ruleset may catch known payload patterns, especially noisy time-delay probes. Determined attackers can obfuscate requests, so secure query construction remains the primary control.
References
Explore authoritative guidance and frameworks related to blind sql injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.