What Is a Race Condition?

A race condition is a bug where the outcome depends on the timing of events happening at once — and when an attacker can influence that timing, it becomes a vulnerability. The system does the right thing in testing and the wrong thing under a precisely timed attack, which makes race conditions both dangerous and hard to spot.

What is the TOCTOU pattern?#

The classic security race is time-of-check to time-of-use (TOCTOU): a program checks something, then acts on it, and an attacker changes the thing in between.

1. Program checks: does user have $100? → yes
2. [attacker fires a second request in the gap]
3. Program acts: withdraw $100
   ...twice, because both checks passed before either withdrawal

This is how attackers double-spend, redeem a coupon many times, or slip a symlink in between a file’s permission check and its use. The window is tiny, but attackers automate thousands of attempts to hit it.

How do you prevent race conditions?#

The fix is to remove the gap — make the check and the action atomic:

Technique	How it helps
Atomic operations	Check and act become one indivisible step
Locks / mutexes	Serialize access to the shared resource
Database transactions & constraints	Enforce invariants at commit, not in app code
Idempotency keys	A repeated request cannot repeat the effect

On the web, the usual culprit is business logic that reads, decides, and writes in separate steps without a lock or transaction — a cousin of business logic flaws.

Race conditions are timing-based logic flaws. More vulnerability classes at the Web Security hub, and foundations at the Security Fundamentals hub.