What Is a Race Condition?

A race condition is a software flaw where the outcome depends on the timing or order of operations. In security, a race condition matters when an attacker can exploit that timing gap to trigger unintended behavior, bypass checks, or perform the same action more than once.

The problem is not just that two things happen at once. The problem is that the system does not handle overlapping actions safely.

Race condition definition

A race condition happens when multiple operations interact with the same state, resource, or decision point, and the final result changes depending on which one finishes first.

That can happen in:

• web applications handling parallel requests
• multithreaded programs
• file operations
• database transactions
• APIs and distributed systems
• permission checks
• payment or redemption workflows

A common security form of this issue is time-of-check to time-of-use, often shortened to TOCTOU.

How a race condition works

At a high level, a race condition appears when software assumes one step will complete before another interfering step occurs.

The system checks a condition

The application first verifies whether an action should be allowed. For example, it may check:

• whether a user has permission
• whether a coupon is unused
• whether a balance is sufficient
• whether a reset token is still valid
• whether a file path is safe
• whether inventory is still available

At that moment, the application believes it has a correct answer.

A gap exists before the action completes

After the check, the application performs the next step, such as:

• granting access
• updating a balance
• redeeming a coupon
• changing account state
• opening a file
• processing an order

If there is a timing gap between the check and the action, another request or process may change the state in between.

The attacker or competing request wins the race

If an attacker can send multiple requests at nearly the same time, or otherwise influence timing, the application may behave incorrectly.

Possible outcomes include:

• a discount code being redeemed more than once
• multiple withdrawals being accepted
• a one-time token being reused
• a permission check passing before access changes
• a file operation affecting a different file than intended
• duplicate purchases or credits being processed

The bug exists because the system did not safely coordinate the shared state.

Common race condition examples

Race conditions show up in several practical ways.

Duplicate transaction processing

An application checks whether a gift card, promo code, or refund request has already been used. If several requests arrive before the “used” status updates, the system may approve the action more than once.

TOCTOU file issues

A program checks whether a file path is safe, then opens or modifies it later. If the file or path changes between those steps, the application may touch something it was never supposed to access.

Token or session reuse

An app validates a one-time token, password reset link, or action approval, but fails to invalidate it atomically. That can let the same artifact be used multiple times under the right timing conditions.

Parallel request abuse

Attackers may send many concurrent requests to endpoints related to wallets, entitlements, checkouts, or account actions to see whether the application mishandles shared state.

For another common application flaw, see our guide to what is sql injection.

Why race conditions are hard to detect

Race conditions are often harder to find than obvious coding mistakes because they can be inconsistent. The issue may only appear when:

• requests arrive in a very small time window
• backend services return in a certain order
• system load changes response timing
• retries or queues alter normal flow
• multiple threads or processes access the same resource simultaneously

That means a feature can appear to work in normal testing but still fail under scale or adversarial conditions.

Where race conditions matter most

You are most likely to encounter race conditions in workflows that involve shared state and one-time actions.

Web application security testing

Race conditions commonly show up in pentests, code reviews, and bug bounty reports involving checkout systems, redemption logic, registration flows, and access control endpoints.

Financial systems

Any system that handles balances, credits, refunds, or inventory is a natural place for timing flaws. If two requests can affect the same value, concurrency safety matters.

File and operating system operations

Race conditions are well known in software that checks file paths, permissions, symlinks, temporary files, or ownership before performing an action.

APIs and distributed systems

Microservices, asynchronous jobs, queues, retries, and eventually consistent systems can all introduce timing problems that create security-relevant race conditions.

If you are reviewing broader secure design patterns, our article on what is open redirect covers another logic-driven web vulnerability class.

How developers reduce race condition risk

Preventing race conditions usually means making critical operations safe under concurrency.

Common approaches include:

• atomic operations
• locking or mutexes
• database constraints
• transaction isolation
• idempotency keys
• queue-based processing
• server-side state validation at the moment of action
• avoiding separate check-then-act logic where possible

The exact fix depends on the application architecture, but the principle is the same: sensitive operations must remain correct even when many requests happen at once.

For developers or power users managing important credentials across systems, Try 1Password → can help reduce account hygiene problems, though it does not fix application-level race conditions. For endpoint protection during broader software testing and day-to-day use, Get Malwarebytes → can also be a practical defensive layer.

Final takeaway

A race condition is a timing-dependent flaw that lets software reach an unintended or unsafe state. In security, that can mean bypassed checks, duplicated transactions, reused tokens, or access to the wrong resource.

If your application handles shared resources, one-time actions, financial logic, or concurrent requests, race conditions are a class of issue worth testing for deliberately.