Glossary
Race Condition
A vulnerability that occurs when the outcome of an operation depends on the execution order of concurrent processes. Race conditions can bypass balance limits, duplicate transactions, or circumvent authorization checks. They are particularly critical in payment systems and fintech APIs.
How a race condition becomes a vulnerability
A race condition occurs when two concurrent operations access the same resource without synchronization, and the outcome depends on execution order. In application security the most common pattern is TOCTOU (time-of-check to time-of-use): the app verifies a condition (sufficient balance, unused promo code, available quota) then acts, but between the two a parallel request changed the state. By firing dozens of simultaneous requests, an attacker slips multiple operations between the check and the action.
Examples in HR or payroll SaaS
Concrete cases abound: spending the same leave balance twice by submitting requests simultaneously, exceeding a billed license or user quota, reusing a single-use invitation or password-reset token, generating two payouts for one expense reimbursement. Modern architectures raise the risk: multiple server instances behind a load balancer multiply concurrency windows when synchronization relies on local memory.
Detection and remediation
In audits we probe sensitive operations with bursts of parallel requests to reveal concurrency windows, in a test environment and with no production impact. On the fix side: database-level uniqueness constraints and locking transactions (SELECT FOR UPDATE, UNIQUE constraints), atomic operations, transactionally consumed tokens, and idempotency on critical endpoints.
Frequently asked questions
Are race conditions really exploitable remotely?
Yes. Modern techniques (multiplexed HTTP/2 requests, single-packet attacks) can land dozens of requests within the same millisecond, making concurrency windows very exploitable even on remote applications.
How do you fix a race condition on a balance or quota?
Move the check into the database: a transaction locking the affected row, a CHECK or UNIQUE constraint, or an atomic operation (UPDATE ... WHERE balance >= amount). Application-level checks alone, even duplicated, do not close the window.
Can unit tests catch these flaws?
Hardly: unit tests run sequentially. You need targeted concurrent load tests on stateful operations (payments, quotas, single-use tokens) or an audit that reproduces real exploitation conditions.