Cybersecurity glossary

What is Time-Based SQL Injection?

Learn what time-based SQL injection is, how SLEEP and WAITFOR delays leak data blindly, how attackers extract information bit by bit, and how to prevent timing-based SQLi.

Application securityUpdated July 20, 2026
Also known asTime-based SQLiTiming-based SQL injectionBlind time-based injection

Definition

Time-based SQL injection is a blind SQL injection technique in which attackers infer database information by intentionally delaying query execution—using functions such as SLEEP or WAITFOR—and measuring whether responses take longer based on true or false conditions.

Why timing becomes an oracle

When applications hide SQL errors and never reflect query results, attackers still need a signal. Time is one of the few signals left: make the database pause only when a condition is true, then measure latency.

Time-based SQL injection turns response delay into a yes/no channel for dumping data blindly.

How a time-based attack works

1

Confirm injectable input

Find a parameter that influences SQL without showing useful output.

2

Inject a conditional delay

Payloads trigger SLEEP/WAITFOR only when a boolean condition holds.

3

Measure response time

Slow responses mean “true”; fast responses mean “false.”

4

Extract data bit by bit

Binary search characters of usernames, hashes, or table contents.

5

Automate at scale

Tools parallelize guesses despite the inherent slowness.

Time-based vs other blind methods

MethodSignalTrait
Boolean blindContent/status differencesOften faster than timing
Time-basedLatency differencesWorks when content is identical
Out-of-bandDNS/HTTP callbacksNeeds DB network features

Defenses and detection

Parameterize everything

Eliminate the injection so delays cannot be injected as SQL.

Least privilege

Limit what a compromised query path can read or execute.

Anomaly detection

Watch for repeated slow queries and SLEEP-like patterns.

WAF / CRS

May catch known timing payloads; do not rely on them alone.

  • Use prepared statements for all untrusted inputs in SQL.
  • Avoid building dynamic SQL with string concatenation.
  • Alert on abnormally high query durations from web tiers.
  • Disable unnecessary database features that enable delays or callbacks.
  • Include blind and time-based cases in penetration tests.
  • Rate-limit abusive request patterns on sensitive endpoints.
  • Keep database and application error handling from leaking schema details.
  • Treat any confirmed time-based SQLi as critical data-exposure risk.

The practical takeaway

Time-based SQL injection abuses query delays as a blind communication channel. If attackers can make your database sleep on command, they can usually extract data—slowly but surely.

Fix the SQL construction. Timing oracles are symptoms; parameterization is the cure.

Related security terms

Frequently asked questions

What is time-based SQL injection in simple terms?

Attackers ask the database to wait if a guess is true. If the page is slow, their guess was right—even when no data appears on screen.

When do attackers use time-based SQLi?

When the application does not return query results or useful error messages—classic blind conditions.

Which SQL functions are commonly abused?

Examples include SLEEP() (MySQL), pg_sleep() (PostgreSQL), and WAITFOR DELAY (SQL Server), among database-specific variants.

Is time-based SQLi noisy?

Yes. It is often slower and more detectable than in-band SQLi, but automation still makes large extractions practical.

How do you prevent it?

The same primary control as all SQLi: parameterized queries. Timing attacks cannot invent syntax if input cannot alter SQL structure.

Can rate limiting stop time-based SQLi?

It can slow extraction and aid detection, but it does not fix vulnerable query construction.

References

Explore authoritative guidance and frameworks related to time-based sql injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary