Race conditions arise when two or more processes access the same resource simultaneously and the result depends on the order in which the operations occur. For example, two parallel requests can redeem the same coupon if both check its status as “not yet used” before either request records the redemption in the database.

The consequence: In security-critical applications, this can allow authorizations, access controls, or integrity mechanisms to be bypassed. Race conditions can thus pose significant security and business risks and should therefore be addressed as part of a comprehensive cybersecurity strategy.

This article provides an introduction to the concept of race conditions, with a focus on security aspects. You will learn how race conditions arise, what typical vulnerabilities they present in web backends and local components, what architectural and process measures can be used to prevent them, and what testing strategy can be used to systematically identify these errors during security assessments and code reviews.

Introduction to Race Conditions

Today, concurrency is a standard feature of modern software architecture. Asynchronous events, multithreading, microservices, container orchestration, and cloud-based scaling ensure that multiple execution threads access states in parallel or quasi-parallel.

While developers often assume a stable sequence of individual processing steps, the operating system breaks down the program logic into interruptible steps. Each of these steps can be delayed by scheduling or I/O wait times. This can create a time window between the verification of an assumption and its subsequent use, during which the underlying state changes. It is precisely within this time window that race conditions arise.

A race condition becomes a security issue when it violates an assumption that the system is actually supposed to guarantee at all times. This can mean, for example, that a user can spend more credit than is available, a token is used multiple times, or an authorization check is based on an outdated state.

Key Terms Related to Race Conditions

To properly classify race conditions and understand their effects, it’s worth taking a look at a few key terms first.

• Invariant: A rule that must apply in the system at all times. Examples include: A coupon may be redeemed only once, a token may not be accepted again after it has been used, or a user may access only their own data.
• Atomic operation: An operation that, from the system’s perspective, is either executed in its entirety or not at all. It is crucial that no other parallel process can contradictorily alter the same state between the check and the state change.
• Synchronization: Technical coordination of parallel accesses, for example through locks, transactions, or other mechanisms that prevent simultaneous contradictory changes.
• Transactional unit: A coherent sequence in which multiple steps are executed together. Either all steps are successfully completed, or none of them takes permanent effect.
• Constraint: A rule enforced by the system, often at the database level. For example, a unique constraint can prevent the same coupon from being stored multiple times as redeemed.
• Idempotence: A property of operations in which repeated execution has the same effect as a single execution. This is particularly relevant when requests are sent repeatedly, in parallel, or resubmitted after an error.
• Consistency window: A short period of time during which different parts of the system observe different states, for example due to replication delays or asynchronous processing.
• Time of Check to Time of Use (TOCTOU): A subcategory of race conditions in which a security-relevant check is performed during program execution and the result is used to make a decision immediately afterward. The system is not in a frozen state between these two points in time. Another process or a parallel request can change the state, causing the original check to be out of date for the subsequent action.
• Data race: This term, used in parallel programming, describes simultaneous accesses to the same variable without sufficient synchronization, particularly when at least one access modifies the value. Initially, this often leads “only” to incorrect or unpredictable program behavior, such as a counter being calculated incorrectly or a state becoming inconsistent. Beyond this, data races can also lead to crashes, memory corruption, or security-relevant vulnerabilities; in languages such as C and C++, they may even result in undefined behavior.

Race Conditions Affect the Entire Company

Race conditions don’t just affect development teams; they can directly impact business-critical processes. In practice, they often occur where multiple actions are processed simultaneously – for example, with regard to coupons, payments, approvals, password resets, role changes, or inventory management. The resulting damage can therefore quickly affect the business level: duplicate redemptions, unauthorized actions, erroneous postings, or exceptional situations in operations that are difficult to trace.

Additionally, there is a governance issue. Traditional control questions such as “Are permissions checked before access?” are not sufficient when it comes to race conditions. What matters is not whether a check is performed, but whether the desired rule is technically enforced. A process description that appears sound can therefore be misleading if enforcement is implemented only logically, but not atomically.

The challenge for companies: Race conditions often do not appear to be obvious vulnerabilities. Many errors only become apparent under heavy load, during concurrent access, or in rare operating conditions. Automated testing tools and traditional code reviews can therefore detect race conditions only to a limited extent. This is precisely why they are easily overlooked in conventional tests or during regular operation, even though they can have significant impacts on security, business processes, and data integrity in the event of a critical incident.

Causes and Chains of Effects

Race conditions typically arise from the interplay of three factors:

1. Interruptible execution: Virtually any section of a program can be interrupted during execution. As a result, the system can perform any other activities between a check and the subsequent use of the result.
2. Non-atomic operations: Many standard operations internally consist of several individual steps. A sequence in which a system first checks whether a certain condition is met and only then changes the state is particularly problematic. Between these two steps, another process can intervene and alter the state.
3. Temporary inconsistencies in distributed systems: In replicated or asynchronously processed systems, data is often not updated everywhere simultaneously, which can cause data sets to diverge from one another for a brief period of time. As a result, two queries may see different data states at the same time.

A logically sound sequence visible in the code is therefore no guarantee of actual, uninterrupted execution.

Example From the Application Layer

A simple example from the application layer can illustrate this: An endpoint checks that a coupon has not yet been redeemed, applies the discount, and only then marks the coupon as redeemed in the database. If the same coupon is shown as unredeemed in two concurrent requests, it can be redeemed twice.

This example shows that security is not ensured solely by an upstream check, but rather by operations in which the check and the state change are atomically linked.

Attack Surfaces in Practice

At the web level, race conditions primarily occur in workflows that span multiple requests or processing steps. These include:

• Password reset flows and email verifications in which tokens are not invalidated atomically
• Coupon and credit logic without clear constraints – that is, when it is not ensured that an action can be executed only once
• Role or ownership changes where only the authorization is checked initially and the actual access occurs later
• Local components can also be affected if an application checks a condition and later accesses the same logical state again

The problem is not limited to specific programming languages. What really matters is the underlying pattern: A state is first checked and only used later. If this state changes between those two points in time, the system may make an incorrect decision.

In distributed systems, race conditions are further intensified by the fact that data is not always updated immediately everywhere. These delays can lead to brief periods of inconsistent data states that are specifically queried or modified. If these are deliberately exploited, actions can be performed that should no longer be permitted. However, the consequences may have already occurred before the system detects the error.

Exploitability and Verifiability

In a penetration test, a race condition is exploitable if:

• a relevant security objective is affected,
• the time window can be reliably met, and
• a clear artifact confirms the success.

A relevant target exists when the core values of confidentiality, integrity, or availability (CIA) are compromised.

The time window can rarely be hit with exact timing, but it can be achieved through parallelization and repetition. In practice, many simultaneous requests with small, random time intervals are often sufficient to statistically reach the critical point.

From a business perspective, it is important that the detectability be measurable. Measurable effects can include double redemptions of one-time tokens, erroneous postings, invalid status changes, or log entries that document the occurrence of a prohibited state.

The proof is not only a matter of timing but also of the testing strategy. The more clearly the unauthorized state is defined and the more unambiguous the expected artifact is, the more robust the finding becomes.

Countermeasures for Race Conditions

Race conditions can lead to significant security issues. Therefore, appropriate countermeasures are necessary to reliably safeguard critical processes.

Why Traditional Checks Are Often Not Enough

Short time windows do not provide protection. Schedulers, I/O wait times, background processes, and network latencies – even in the millisecond range – are sufficient for a race condition to occur statistically.

Even the reference to “additional checks” often falls short. If a business rule is merely checked multiple times but not technically enforced, the vulnerability remains. This is especially true when multiple systems, services, or requests are involved.

Even database transactions are not a panacea if the technical uniqueness is not safeguarded by appropriate constraints. What matters is not the number of protective mechanisms, but whether the security invariant is strictly enforced at the right point.

What Constitutes Robust Countermeasures

Effective countermeasures technically enforce the desired invariant. At the database level, unique constraints, atomic updates, and idempotency keys are central building blocks. At the application level, critical state changes should be modeled in such a way that business rules are not only checked but also enforced within the same operation.

Equally important is the architectural perspective. Security rules should be implemented where they can be enforced bindingly – for example, in the database schema or in atomic system operations – and not merely in upstream plausibility checks. For the management, this means that security quality is not achieved solely through additional testing, but rather through architectural decisions.

Another key to success is the clear definition of business invariants. As long as it remains unclear what “exactly once”, “only the owner”, or “only in the approved state” technically mean, gaps can easily arise between business logic and implementation.

Testing Strategy in Assessment and Code Review

Race conditions are rarely detected through individual tests. Meaningful testing relies on targeted concurrency, parallelization, repetition, and measurable success criteria. It is crucial to not only look for technical defects but also to use business rules as test criteria.

As part of a penetration test or application security assessment, it therefore makes sense to specifically examine particularly critical workflows for race conditions – such as payment logic, token flows, approval processes, authorization changes, or inventory operations. The added value lies not only in exposing individual vulnerabilities, but also in identifying recurring design patterns that create the same risk in multiple parts of the system.

Conclusion – Race Conditions as a Security Risk

From a security perspective, race conditions are a structural problem in modern software; from a business perspective, they represent a quality and business risk directly related to core processes. They do not arise from “poor timing”, but rather from a design that relies on stable intermediate states without technically ensuring that stability.

Robust systems avoid this assumption. They rely on atomic operations, unambiguously enforced rules in the data model, and tests that realistically simulate concurrency. Especially for security-critical applications, targeted testing as part of application security testing and code reviews is therefore worthwhile, because it not only helps to identify individual bugs but also sustainably improves the resilience of core business processes.

Having Systems Inspected

Oneconsult offers various ways to test and specifically improve the resilience of your applications and processes against vulnerabilities caused by race conditions.

• In the field of penetration testing – and particularly in application testing – critical web and API workflows can be systematically examined for vulnerabilities such as faulty state transitions, inadequately secured one-time operations, or timing issues.
• In addition, a security assessment can help identify recurring risks at the architectural and process levels and determine appropriate measures. Our Cybersecurity Academy offers hands-on training to build expertise within development and security teams.