What is a race condition?

Web requests run concurrently. A race condition exists when an application checks a condition and then acts on it as two separate steps, assuming nothing changes in between.

An attacker who fires many requests at the same instant can slip multiple actions into that gap before the state updates. The classic shape is time-of-check to time-of-use (TOCTOU): the app verifies a balance or a one-time flag, but several requests pass the check before any of them updates it.

The attacker sends a burst of identical requests timed to arrive together:

• Redeem a single-use coupon many times: 50 simultaneous redeem requests all pass the "unused?" check before the first marks it used.
• Overdraw a balance: parallel withdrawals each see the original balance.
• Bypass a rate or quantity limit by racing past the counter update.
• Modern tooling sends requests in a single packet to minimise timing jitter.

Examples shown for defensive context.

• Make critical operations atomic: enforce uniqueness and limits at the database (unique constraints, conditional updates like UPDATE ... WHERE balance >= amount).
• Use locking or transactions so a check and its action cannot be split by concurrency.
• Avoid read-then-write logic in application code for limited resources.
• Idempotency keys for operations that must happen once.
• Test sensitive endpoints with concurrent/parallel requests, not just sequential ones.