HighA06:2025CWE-362Business Logic

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.

Race Condition DetectionConcurrent Request Testing

Scan a domain you have verified with up to 350 modules, paid in credits.

See how website scanning works

References

Related Vulnerabilities