BERRY9 IT Services, home +91 86868 92922

Race Conditions and TOCTOU Bugs in Web Applications

Race conditions in web applications — the classic time-of-check-to-time-of-use (TOCTOU) bug — are invisible to scanners and obvious to humans once you know what to look for. They turn a system that should be safe into a system that lets the attacker double-spend, double-redeem, double-vote, or trivially exceed any quota.

Web applications · By Thimmagurudu Bathini · Published · 6 min read · Last reviewed

The pattern

Two requests arrive within milliseconds of each other. Both pass the same check ("does the user have credit?", "has the coupon been used?", "is the OTP valid?"). Both then perform the same state change. The check happened before the state change committed for either; both succeed.

Where we find them

  • Coupon and gift-card redemption — redeem the same code from 50 parallel requests, get N copies of the credit
  • Wallet withdrawals and transfers — empty a wallet faster than the ledger catches up
  • OTP retries — race a single OTP against multiple verification attempts to brute-force
  • Rate limits — burst past the limit before the counter persists
  • One-time tokens — password resets, email confirmation, magic links

How we test

Burp Repeater's group/parallel mode, or a simple Python script that fires 50 requests concurrently. We then check whether the post-condition is the intended one. Many applications are vulnerable to at least one race, and in payment flows the result can be a balance spent many times over.

The fix

Database-level locks or atomic operations (UPDATE ... WHERE ... AND credit > amount RETURNING ...). Application-level mutexes are weaker but workable for some flows. Idempotency keys on state-changing endpoints prevent retry duplication. We cover this in detail in our code review service.

Written by Thimmagurudu Bathini, BERRY9 IT SERVICES PRIVATE LIMITED, Hyderabad. Questions about your own systems? Request a scoping call or call +91 86868 92922.

Plan your next security test

Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.