Race Condition Attacks

A race condition happens when an application checks something and then acts on it, and an attacker squeezes a second request into the gap between the two. Sending many requests at exactly the same moment can redeem a coupon twice, withdraw money twice, or bypass a limit. It is a timing bug, and it is tested by firing simultaneous requests.

What a race condition is

Most logic follows a pattern: check a condition, then perform an action. The gap between check and action is a window. If two requests both pass the check before either performs the action, both proceed, even though only one should have. That window is the vulnerability.

Real examples

How to test

Send many identical requests as close to simultaneously as possible, so several land inside the check to action window. Modern tooling, including Burp, can fire requests in a single packet burst to maximise the overlap.

# conceptually: fire 20 identical requests at once
# if a single-use action succeeds more than once, race condition

Why it is missed

Race conditions do not show up in normal testing because normal testing sends one request at a time. The application works perfectly sequentially and breaks only under concurrency. That is why scanners miss them and manual concurrency testing finds them.

The fix

1. Make the check and action atomic, so they cannot be interrupted
2. Use database locking or transactions around the critical section
3. Enforce uniqueness at the database level, not just in application logic
4. Use idempotency keys for sensitive operations

Practise this

Race conditions are among the most rewarding bugs in bug bounty because they are so often overlooked. Practise on vulnerable apps on Hacklido.