Home / Knowledge hub / Time of check to time of use
Knowledge hub
Time of check to time of use
A gap between checking a condition and acting on it that an attacker can use.
What it means
Time of check to time of use, often shortened to TOCTOU, is a flaw where a program checks something, then acts on it a moment later, and the thing changes in between. The check was correct when made. By the time of use it is no longer true.
A classic web example: your code checks that an account has enough balance, and then deducts it. Two requests arriving together can both pass the check before either deduction is made. It is a close relative of the race condition.
Why it matters
The gap is usually tiny, but attackers can send requests fast enough to land in it, and scripts make that easy. The results are money spent twice, a coupon redeemed repeatedly, a limit exceeded or a permission used after it was withdrawn.
Because each request is valid and the checks are in place, ordinary testing passes. Logs show two normal requests. Only reconciliation reveals that the totals do not add up, which makes it a flaw people find late.
How it shows up
You meet it in balances and wallets, stock counts, one-per-customer offers, invitation and voucher use, file handling, and permission checks followed by long-running actions. The mistake is a check and an update that are separate steps with nothing holding the data still between them.
The fix is to make the check and the action one atomic step: a database transaction with a lock, a conditional update that fails if the value changed, or a unique constraint that refuses a second use. Test by firing the same request many times at once and checking the result. See also limit overrun and double spend.
Questions people ask
Time of check to time of use, answered
Is TOCTOU the same as a race condition?
It is a specific kind. A race condition is any outcome that depends on timing. TOCTOU is the case where a check and a later action are separated, and the state changes between them.
Can it happen in web applications?
Yes. Any time a server checks a condition and then updates the data in a separate step, simultaneous requests can both pass the check. Balances, coupons and stock are common cases.
How do we fix it?
Combine the check and the update so they cannot be separated: use transactions with locking, conditional updates, or unique constraints in the database. Do not rely on checking in application code alone.
Why do normal tests miss it?
Tests send one request at a time. The flaw needs several arriving at nearly the same moment, so it only shows when testing sends requests in parallel.
How do we test for it?
Send the same request many times at once, such as redeeming a voucher or withdrawing a balance, and check whether more than one succeeds. The proof is the final state of the data.
Sources
Where this comes from
Related
Terms that sit next to this one
Race condition
Two near-simultaneous actions producing a result neither should allow.
Limit overrun
Exceeding a cap, such as one redemption per customer, with parallel requests.
Double spend
Using the same balance, credit or voucher twice by acting faster than your checks.
Coupon abuse
Using a discount code more times, or in more ways, than you intended.
State machine abuse
Moving an order or account into a state the normal flow would never reach.
What changes between check and use?
We send requests in parallel to see whether a check and an action can be split, and the proof is the resulting data, not a theory. Each finding includes the requests. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.