A web race condition is a flaw where two or more concurrent requests reach a web application in the wrong order, producing an unintended state. It usually appears when authentication, session, balance, or privilege checks are split across separate steps without atomic locking or other synchronisation.
What Web Race Conditions Mean in Practice
Web race conditions happen when concurrent requests collide and the application processes them in an order the developer did not intend. The underlying problem is usually not concurrency itself, but business logic that assumes each step will complete before the next request can alter the same account, balance, session, or permission state.
They are especially dangerous in web applications because timing gaps are often tiny, hard to reproduce, and easy to overlook in testing. A flow that looks safe with a single request can become unsafe when two tabs, retries, automated scripts, or parallel API calls reach the same state-changing endpoint at once.
How Race Conditions Break Web Application State
The classic failure pattern is a time-of-check to time-of-use gap. A request passes an initial validation step, then another request changes the shared state before the first request finishes, so the final action is applied to stale assumptions. That is why race conditions are often associated with duplicate purchases, double spends, privilege changes, or inconsistent session state.
Atomicity matters more than the individual checks. If authentication, balance verification, quota enforcement, or permission checks are split across multiple steps, the application may need locking, isolation, idempotency, or a single transactional boundary to keep the state coherent. NHIMG’s Race Condition Vulnerabilities Guide covers the core design patterns that help eliminate these flaws.
Where Web Race Conditions Most Often Appear
Race conditions are common anywhere one user action consumes a scarce or security-sensitive resource. Checkout flows, password reset flows, onboarding and offboarding steps, role changes, token issuance, and account recovery logic are all frequent candidates because they mix user interaction with state transitions that must remain ordered.
They also appear in modern distributed web systems where multiple app servers, queues, workers, or retries touch the same record. Even when each component is correct on its own, the overall workflow can still fail if the system does not enforce a single source of truth for state transitions.
Race conditions are a broad software weakness class, and they often show up alongside other concurrency flaws in the CWE Top 25 Guide. In practice, the same design review should look for stale reads, missing locks, and broken assumptions about request ordering.
Detection, Testing, and Remediation Patterns
Finding these flaws usually requires deliberate concurrency testing rather than ordinary functional testing. Teams look for duplicate actions, inconsistent records, unexpected state rollback, and symptoms that only appear under high parallelism, retries, or network delay. On the defensive side, those patterns often point to missing synchronization or insufficient enforcement of uniqueness and ordering.
Remediation usually means redesigning the workflow so the critical decision and the state change happen together. That may involve transactional updates, row or object locks, compare-and-swap style checks, idempotency keys, stricter state machine rules, or moving the sensitive transition behind a single authoritative service boundary. For web workloads, the goal is to make the unsafe interleaving impossible rather than merely unlikely.
For deeper attack-path context, the concurrency issue itself is distinct from the exploit technique, but the same defect class can be used for abuse such as bypassing quotas, duplicating value, or forcing inconsistent authorization decisions. Public GitHub artifact leaks in ArtiPACKED 2024 are a useful reminder that timing mistakes and state handling failures can expose security-sensitive material in unexpected ways.
Risk and Threat Considerations
Web race conditions create security exposure because the application may make a “safe” decision on outdated state, then complete an action that should no longer be allowed. Attackers look for these gaps because they can be triggered repeatedly, scaled with automation, and used to bypass business rules that assume orderly request processing.
Failure mechanism: Two or more requests interleave around a non-atomic check, so the application validates one state but commits another, allowing duplicate or unauthorized outcomes.
Impact: The result can be financial loss, broken access control, inconsistent account state, duplicate transactions, or privilege changes that should never have been accepted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-4 — Information in Shared System Resources | Race conditions arise when shared state is exposed across concurrent requests. |
| Recommendation — Partition shared state so concurrent web requests cannot corrupt or reuse security-sensitive data. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Safe web concurrency depends on hardened workflow and application settings. |
| Recommendation — Harden application and server settings to reduce unsafe concurrent execution paths. | ||
| OWASP ASVS | V8 — Authorization | Out-of-order requests can bypass authorization and state-change checks. |
| V7 — Session Management | Race conditions can corrupt session state or allow session-related abuse. | |
| Recommendation — Verify that authorization decisions stay valid across the full request lifecycle. Protect session transitions with atomic updates and single-use state changes. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Race-condition abuse is an exploitation technique that can trigger unintended program behavior. |
| Recommendation — Map observed concurrency abuse to attack techniques and alert on repeated trigger attempts. | ||
Practitioner Guidance
What practitioners should watch for: Treat any workflow that changes balance, privilege, session, or ownership as a state machine, not just a sequence of HTTP handlers. If a user can repeat, race, or parallelise the action, the design needs an explicit guardrail for ordering and atomicity.
Governance implication: The safest review habit is to require an owner for every state transition and to verify that the implementation prevents duplicate or out-of-order execution under load, retry, and multi-node conditions.
Related resources from NHI Mgmt Group
- What do teams get wrong about race conditions in WebSocket systems?
- How should security teams implement parallel execution in .NET without creating race conditions in security-critical code paths?
- How should security teams implement asynchronous code controls in CI/CD pipelines to avoid race conditions and hidden failures?
- Who is accountable when periodic reconciliation jobs miss race conditions or stale state?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org