Cybersecurity glossary
What is a Race Condition?
Learn what a race condition is, how concurrent requests create TOCTOU and double-spend bugs, how attackers exploit timing windows, and how locking and atomic operations prevent them.
Definition
A race condition is a flaw that occurs when a system’s behavior depends on the unpredictable timing or interleaving of concurrent operations, allowing attackers to perform actions twice, bypass checks, or corrupt state by winning a timing window.
Why race conditions matter
Many application checks assume one request at a time: “If balance >= amount, then debit.” Under concurrency, two requests can both pass the check before either debit lands. The result is a negative balance, a double purchase, or a reused one-time code.
Race conditions turn timing into an exploit primitive. They are especially profitable in commerce, fintech, gaming, and any workflow that consumes a scarce resource exactly once.
How race condition attacks work
Identify a one-time or scarce action
Coupon redeem, seat hold, payout, vote, or token consumption endpoints.
Map the check-then-act logic
Find where the app reads state, decides, then writes—without atomicity.
Send parallel requests
Issue many concurrent requests for the same action with the same credentials.
Win the timing window
Multiple requests pass the check before state updates complete.
Observe broken invariants
Extra credits, oversold inventory, or duplicated side effects appear.
Automate reliably
Tooling tightens timing (single-packet tricks, connection warming) for consistent wins.
Common vulnerable patterns
Coupon / credit reuse
One code applied many times through concurrent redeem calls.
Balance double-spend
Two transfers both pass a balance check against the same funds.
Inventory oversell
Limited stock decremented non-atomically across shoppers.
TOCTOU file/object access
Permission checked, then object replaced or path changed before use.
Fixes that preserve invariants
| Technique | Role |
|---|---|
| Atomic database updates | Single statements/constraints that enforce limits (for example, WHERE balance >= amount) |
| Transactions + isolation | Serialize critical sections with appropriate isolation and retries |
| Unique constraints | Make double inserts of one-time redemptions impossible |
| Idempotency keys | Clients and servers agree that retries do not duplicate side effects |
| Distributed locks (careful) | Coordinate across services when a single DB constraint is insufficient |
- Express business invariants in the database, not only in application if-statements.
- Mark one-time tokens consumed atomically; reject concurrent second uses.
- Load-test critical flows with intentional parallel requests in staging.
- Use idempotency keys for payment and provisioning APIs.
- Avoid check-then-act on files and object storage without compare-and-swap semantics.
- Do not rely on rate limits as the sole race defense.
- Review microservice workflows where two services update related state.
- Monitor for duplicate fulfillments and negative balances as security signals.
The practical takeaway
A race condition lets attackers exploit concurrent timing to break application invariants. If a resource should be used once, the system must make “once” true under parallelism—not merely under polite single-threaded use.
Design atomic operations, enforce constraints, test with concurrency, and treat duplicate side effects as both reliability and security failures.
Related security terms
Business Logic Flaws
Race conditions frequently enable business logic abuses like coupon reuse.
API Abuse
Automated concurrent requests are a common way to win race windows.
Rate Limiting
Helps reduce automated concurrency but does not replace atomic business checks.
Insecure Direct Object Reference (IDOR)
Sometimes combined with races in multi-step object workflows.
Frequently asked questions
What is a race condition in simple terms?
A race condition happens when two things happen at nearly the same time and the system is not prepared for that. Attackers send parallel requests to do something twice—like redeeming one coupon two times—before balances update.
What is TOCTOU?
Time-of-check to time-of-use: the application checks a condition, then later uses a resource assuming the condition is still true, while another request changed it in between.
Where do web race conditions appear?
Coupon redemption, limited inventory checkout, balance transfers, vote counting, invitation acceptance, and one-time token consumption.
Can databases alone prevent races?
Only if you use proper transactions, constraints, and atomic updates. A naive read-then-write pattern remains racy even on a database.
Does rate limiting fix race conditions?
It can make winning harder but is not a correctness fix. Atomic business operations are required.
How do you test for race conditions?
Send many parallel requests for the same one-time action and see if invariants break—balances go negative, coupons reuse, or inventory oversells.
Are race conditions only a security issue?
They are reliability bugs that attackers can weaponize. Security impact appears when concurrency breaks authorization or financial invariants.
References
Explore authoritative guidance and frameworks related to race condition.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.