Cybersecurity glossary
What is Time-of-Check to Time-of-Use (TOCTOU)?
Learn what TOCTOU (time-of-check to time-of-use) is, how races between validation and use bypass security checks, classic filesystem and web examples, and how to prevent TOCTOU with atomic operations.
Definition
Time-of-Check to Time-of-Use (TOCTOU) is a race-condition pattern in which a program validates a condition (the check) and later acts on a resource assuming the condition still holds (the use), while an attacker changes the resource in between and bypasses the intended control.
Why TOCTOU matters
Security decisions are only as durable as the assumptions they freeze. If a program checks a file, balance, or permission and later uses that result without holding the world still, attackers race the gap.
Time-of-Check to Time-of-Use (TOCTOU) is the name of that gap. It bridges classic Unix symlink races and modern API double-spend bugs: the check was true, the use is no longer safe.
How a TOCTOU race works
Program checks a condition
It verifies permissions, balance, file type, coupon validity, or path safety.
Attacker changes shared state
A parallel request or symlink swap alters the resource the check described.
Program uses the stale conclusion
It opens the path, debits once, or grants access based on the old check.
Policy is bypassed
Privileged files are read, coupons redeem twice, or quotas go negative.
TOCTOU arenas
Filesystem races
stat/access then open on a mutable path; symlink substitution attacks.
Web business logic
Check inventory or balance, then update—without atomic transactions.
Token consumption
Validate a one-time token, then mark used after a parallel redeem succeeds.
Configuration reloads
Policy checked against a file that an admin replace mid-operation.
Closing the gap
| Control | Notes |
|---|---|
| Atomic file APIs | Operate on file descriptors; O_NOFOLLOW/O_EXCL; fstat after open |
| Database transactions | Check and update in one atomic transaction with proper isolation |
| Compare-and-swap | Update only if version/state still matches the checked value |
| Unique constraints | Let the DB reject double redemption of one-time tokens |
| Mutexes / locks | Hold locks across the entire check-and-use critical section |
| Idempotency keys | Make duplicate concurrent requests safe by design |
- Find security checks that are separated from the action they authorize.
- Replace path-based checks with fd-based operations where files are involved.
- Wrap balance/inventory/coupon flows in atomic transactions.
- Add unique DB constraints for one-time tokens and single-use codes.
- Test with parallel requests and race tooling on sensitive endpoints.
- Avoid access()/stat() then open() privilege patterns on shared hosts.
- Document locking order for multi-resource operations.
- Monitor for duplicate side effects (double emails, double charges).
The practical takeaway
TOCTOU is a race where a passed check is no longer true at use time. Collapse check and use into one atomic operation whenever security depends on both.
If your code says “if allowed, then do it” across two steps on shared mutable state, assume an attacker will run both steps at once.
Related security terms
Race Condition
Broader concurrency flaw class that includes TOCTOU patterns.
Business Logic Flaws
Web TOCTOU races often enable logic abuses like double spend.
Insecure Temporary File
Temp-file creation is a classic filesystem TOCTOU hotspot.
Privilege Escalation
Filesystem TOCTOU has historically enabled privilege gains on shared hosts.
Frequently asked questions
What is TOCTOU in simple terms?
The program checks that something is safe, then later uses it. Between those moments, an attacker swaps the thing for something unsafe—so the check passed but the use is dangerous.
Is TOCTOU only about files?
No. Classic examples are filesystem races (symlink swaps), but the same pattern appears in web apps: check balance, then debit; check coupon, then redeem—while parallel requests intervene.
How do filesystem TOCTOU bugs work?
Code may access()/stat() a path, conclude it is safe, then open() it. An attacker replaces the path with a symlink to a sensitive file in between.
How do you prevent TOCTOU?
Avoid separate check and use. Prefer atomic operations: open with safe flags and fstat the file descriptor, use transactions/row locks for business checks, and compare-and-swap patterns.
Does locking always fix it?
Correct locking or atomic APIs help when they cover the whole critical section. Locking only the check, or locking the wrong resource, still leaves a race.
How do you test for TOCTOU?
Send concurrent requests, use race tooling, and on filesystems attempt symlink swaps during privileged operations. Look for double spends and inconsistent state.
How is TOCTOU related to race conditions?
TOCTOU is a specific race pattern: a security-relevant check is separated in time from the use that relies on it.
References
Explore authoritative guidance and frameworks related to time-of-check to time-of-use (toctou).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.