Race Condition

A race condition is a timing bug. It appears when an application assumes that operations happen one after another, but an attacker forces them to happen at the same time. The classic shape is a time-of-check to time-of-use (TOCTOU) gap: the application checks a condition (does this coupon have balance?) and then acts on it (apply the credit), and the attacker squeezes extra actions into the window between the two.

Why It Matters

Race conditions are dangerous precisely because each individual request is legitimate, so they evade input-focused tools just like business logic vulnerabilities do. They are also non-deterministic: the same code can behave correctly thousands of times and fail catastrophically when the timing aligns, which means traditional sequential testing almost never triggers them. That combination, high impact and low detectability, makes them some of the most rewarding finds in bug bounty and API security testing.

How a Race Condition Works

Imagine a coupon worth one use. Normally the flow is:

1. Request arrives; the server checks the coupon is unused.
2. The server applies the credit and marks it used.

Now an attacker sends 50 redemption requests at the exact same moment. If all 50 reach step 1 before any of them completes step 2, the server validates them all against the same "unused" state and applies the credit 50 times.

Check Condition

→tiny window

Attacker Alters State

→

Use Stale Result

The logic was correct for one request at a time, but it broke under concurrency. That gap, between check and use, is where the attack lives.

Where Race Conditions Appear

How to Test

Find single-use or limited actions, then fire many identical requests as close to simultaneously as possible. Burp Suite Repeater can send a group of requests in parallel, and a short Python script using async requests can do the same.

How to Prevent Them

Defending against race conditions means removing the assumption of a safe execution order:

• Locking: mutexes, semaphores, or database row locks so only one operation touches the resource at a time.
• Atomic operations: combine the check and the action into one indivisible step.
• Idempotency keys: ensure a repeated request takes effect only once.
• Database constraints: uniqueness, optimistic locking (version numbers), or SELECT ... FOR UPDATE.

Race conditions reward hunters who understand an application deeply enough to know which actions are supposed to happen only once, then prove that, under pressure, they happen more.