Race condition

What it means

A race condition happens when two operations overlap and the result depends on which one arrives first. Whoever wrote the code assumed requests arrive one at a time. In production they do not.

The classic pattern checks something and then acts on it. The application confirms the balance is sufficient, then deducts it. A second request landing in the gap sees the same balance the first one saw. Both checks pass, both deductions happen, and MITRE describes exactly this case in CWE-362.

Why it matters

The damage is usually financial and repeatable. A voucher redeemed fifty times, a refund issued twice, a withdrawal beyond the balance, a single-use invitation accepted by a dozen accounts, a booking system overselling the last seat.

What makes it awkward is that nothing broke. There is no error and no alert, and the log shows a sequence of requests that each look entirely legitimate. Reconciliation the following month is often how anyone notices, if anyone does.

How it shows up

It is hard to see by reading code, because the flaw lives in the timing rather than in any single line. It is easy to trigger on purpose by firing the same request many times at once, which is how PortSwigger's limit overrun examples work.

Look at anything involving money or stock, voucher redemption, one-time links, registration on a field that must be unique, approval steps, and anywhere a check is followed by a write. The fixes belong at the database: a lock, a transaction with the right isolation, or a unique constraint that makes the second attempt impossible rather than merely unlikely.