Race Conditions in Web Applications 

**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.** 

Race conditions are a type of weakness due to the mistakes in the way applications manage concurrent operations. This type of weakness is subtle and typically difficult to discover, but if detected by an attacker and exploited, it can have catastrophic effects.  

A race condition occurs when two or more operations execute in parallel, and the final state of the application depends on the order in which those operations complete. If the application does not correctly manage its concurrent executions, the application may be in a state of inconsistency—or worse, allow an attacker to further exploit assigned privileges and violate the application’s security. The race condition is illustrated most often in the business logic of an application, where it is typical that multiple processes may read and write shared data variables without controlled synchronization. 

The Race Window 

Part of the concept of a race condition is the “race window.” A brief period of time in which the application is in a temporary state of vulnerability. The race window is usually bounded by the time a condition is checked in the application and the time an action based on that condition is completed. If two operations check the condition at nearly the same time in the application, and both take action before the state is updated, both operations may succeed—a violation in the application. 

One of the best-known examples of this vulnerability is the time-of-check to time-of-use (TOCTOU) problem. In this case, the system checks a condition (for example, “Has this discount code been used?”) and performs an action based on that condition without doing another check right before they perform the action. 

Exploiting Race Conditions 

A common scenario would be in the e-commerce checkout process, where stores that provide discount codes only allow for one-time use. Let’s say our server logic has three steps:  

1. Check the discount code to see if it has been used.  

2. If it is valid, apply the discount.  

3. Update the DB to record that the code had been used. 

If you later attempt to reuse this code, the initial validation logic should detect that the code has already been used and prevent further application of the discount. 

Image Sources: Race conditions | Web Security Academy 

An attacker can exploit this validation logic by sending two nearly simultaneous requests using the same discount code. 

1. If the server handles both requests in parallel 

2. Both requests check the status of the code before either one marks it as used. 

3. Since neither has yet updated the record, both validations succeed. 

The system enters a race window – a short period of time between the initial check and the final database update that allows it to perform one action, but not the one that is planned. During the race widow, multiple different processes may manipulate stale data, which can lead to double buying the item or other unintentional actions. 

Walkthrough: Limit Overrun Race Condition 

URL: Lab: Limit overrun race conditions | Web Security Academy 

GOAL: To buy the Lightweight L33t Leather Jacket for a discount price by using a race condition in the discount code workflow. Credentials Provided: Username: wiener, Password: peter 

A. Log In and Observe Normal Purchase Flow 

1. Log in using the provided credentials (wiener:peter). 

2. Add Lightweight “l33t” Leather Jacket item to your cart and apply the provided discount code during checkout. 

3. In Burp’s Proxy > HTTP history, look for: POST /cart/coupon – applies discount code. 

Confirm that only one discount is accepted, and further attempts return “Coupon applied.” 

B. Establish Race Window Timing (Sequential Test) 

1. Remove any existing discount code from the cart. 

2. Send a valid POST /cart/coupon request to Repeater. 

3. Group the tab (Right-click > Add tab to group > Create tab group). Then click on Create button. 

4. Right-click the tab → Duplicate tab-> Select 19 times → Click on Duplicate -> now you have 20 tabs. 

5. In this group, select Send group in sequence (separate connections). This will request each request one after the other in the order of the tabs.  

For each request:  

1. New connection to the server is made.  

2. Request is sent.  

3. Connection is closed before the next request. 

6. Observe the responses: 

1. First tab: “Coupon applied” 

2. Remaining tabs: “Coupon already applied” 

This confirms that the application logic is sound—when requests are not racing. It helps in establishing a baseline behavior before launching the actual exploit. 

 C. Exploit the Race Condition (Parallel Attack) 

1. Remove the coupon from your cart again. 

2. Reuse the same grouped POST /cart/coupon tabs. This time, select Send group in parallel (single-packet attack). This sends requests from all of the group’s tabs at once. 

3. Observe that multiple responses may now say “Coupon applied”. 

This indicates that the race condition successfully used the discount more than once. 

4. Return to your browser and refresh the cart. Verify if the order total has been reduced on multiple occasions (more than 20% off). If the order total remains excessive, remove the discounts again. Add more duplicate tabs(100) and repeat the parallel coupon attack until it remains within your store credit limit. 

Once the total is sufficiently low, click on Place order to purchase the jacket. 

5. The lab is solved and order is on the way. 

This demonstrated how race conditions, particularly limit overrun attacks, can arise when web applications process requests concurrently without proper synchronization. By exploiting the narrow race window between checking a condition and updating the application state, an attacker can bypass single-use restrictions—such as applying a discount code multiple time. 

Using Burp Suite’s Repeater group features, we saw how: 

1. Sequential requests respect the application’s business logic, and 

2. Parallel requests using the single-packet attack can exploit the vulnerability by overwhelming the backend before it registers state changes. 

Caught feelings for cybersecurity? It’s okay, it happens. Follow us on LinkedIn and Instagram to keep the spark alive.