Web › Module 6 › Lesson 1
Race Conditions & TOCTOU
When two requests win a timing race, business rules can break
Visual · web_developer
Race conditions happen when shared state is checked and updated without atomic protection.
Opening
Two clicks, one coupon
Imagine a shop that lets each user redeem a gift code once. You click Redeem twice almost at the same time. Both requests read “not used yet,” both write “used,” and both grant a discount. That is a classic limit-overrun race.
1. What is a race condition?
A race condition occurs when the outcome depends on the unpredictable order of concurrent operations. In web apps this usually means two HTTP requests processing the same account, coupon, balance, or file at once. TOCTOU (time-of-check to time-of-use) is the common pattern: the app checks a condition, then later uses that result without locking—so another request can change reality in between.
2. Where races show up
Limits & quotas
One free trial, one vote, max 5 invites, “use once” promo codes.
Money & inventory
Withdrawals, cart checkout, stock counters, gift card balances.
Multi-step flows
Confirm email → set password → grant role, if steps can be interleaved.
3. Methodology (Cyberlium)
1) Predict collisions — what shared resource can two requests touch? 2) Probe for clues — delays, inconsistent responses, duplicate side effects. 3) Prove the concept — send parallel requests (Repeater / Turbo Intruder style tooling) on your lab only. 4) Fix — atomic DB transactions, unique constraints, idempotency keys, row locks.
Ethics
Race testing can create duplicate charges or corrupt data. Practice only in Cyberlium labs or systems you own.
Knowledge Check
TOCTOU means:
Multiple choice