Race Condition / TOCTOU
Race conditions occur when multiple concurrent requests exploit timing gaps between checking a condition and acting on it (Time of Check to Time of Use). This can lead to double-spending, exceeding limits, or bypassing restrictions.
Overview
Race conditions in web applications occur when the application checks a condition (e.g., account balance) and acts on it (e.g., debit funds) in separate, non-atomic steps. By sending multiple concurrent requests, attackers can exploit the timing gap to bypass balance checks, exceed limits, claim rewards multiple times, or create duplicate transactions.
Impact
Double spending, exceeding account limits, duplicate transactions, inventory underselling, bypass of rate limits.
Examples
Double Spending
Account balance: $100 Simultaneously send 2 requests to transfer $100 Both pass balance check => $200 transferred from $100 balance
Remediation
Implement atomic operations, use database transactions with proper isolation levels, apply pessimistic or optimistic locking, and use idempotency keys for financial operations.
Use database transactions with proper isolation levels
Implement pessimistic locking for critical operations
Use idempotency keys for all financial transactions
Implement optimistic concurrency control with version checks
Test with concurrent request tools
Related SuperClue scanner checks
These scanner checks look for signs of Race Condition / TOCTOU. What a scan can confirm from outside depends on your application.
Scan a domain you have verified with up to 350 modules, paid in credits.
See how website scanning works