Caught in the Race: How Race Conditions Threaten Your Web App’s Security

In the fast-paced world of web applications, milliseconds can make the difference between a secure transaction and a security breach. Imagine two hackers in a digital race, both trying to hit a vulnerable endpoint at the exact same time. That’s not just an action movie plot—it’s the foundation of a race condition attack.

Race conditions are often overlooked but can lead to devastating consequences. They’re not just bugs; they’re security flaws waiting for an attacker with the right timing (and a bit of creativity). In this article, you’ll learn what race conditions are, why they’re dangerous, real-world examples, and—most importantly—how to defend your app before someone else “wins the race.”

What Exactly is a Race Condition?

A race condition occurs when a system’s output or state depends on the precise sequence or timing of uncontrollable events, like two requests being processed simultaneously. If your application doesn’t anticipate this, users (or attackers) might manipulate outcomes by simply acting faster or at the same time as someone else.

Two users try to buy the last pair at the exact same second. If your website only checks stock after both payments are processed, congratulations—now you owe one customer a pair of shoes you don’t have!

Real-World Race Condition Attack Scenarios

Double Purchase Bug

This classic bug appears in many e-commerce sites. Imagine an attacker discovers that by sending two purchase requests at the same time for an item with only one unit in stock, the backend processes both requests before updating the stock. Result? The item is sold twice, breaking inventory and accounting logic.

Free Credits or Double Withdrawals

Some fintech apps have been caught off guard when attackers send simultaneous requests to withdraw funds or redeem coupons. If the backend is not transaction-safe, an attacker can end up with double credits or a free “bonus” at your expense.

Why Are Race Conditions Dangerous?

• Data corruption: Multiple users can modify the same data simultaneously, leading to inconsistencies or overwrites.
• Security bypass: Rate limits, permission checks, or business rules can be sidestepped.
• Privilege escalation: Sometimes, users can gain extra permissions or perform actions they shouldn’t.
• Financial loss: Double-spending or unauthorized transactions are real risks for businesses.

PoC

For this Proof of Concept (PoC), I’ll be using a virtual lab from PortSwigger Academy. In this scenario, the target web application is vulnerable to a race condition that makes it possible to redeem more discount coupons than the system is supposed to allow.

So, this is the request that applies the coupon:

I’ll now send several of these requests in parallel, aiming to apply the coupon multiple times—even though the app should only allow it once.

For this test, I set up 50 requests in Burp Suite and sent them all at once.

Hell yeah! We managed to apply the coupon enough times to buy the item.

By sending a burst of parallel requests, we tricked the application into applying the coupon multiple times—bypassing the intended one-per-user limit. This classic race condition allowed us to stack discounts far beyond what the developers intended, essentially letting us purchase the item for free (or at a massive discount).

This shows how, without proper protection against simultaneous requests, even simple business logic can be abused by attackers willing to “race” the application.

How to Defend Against Racing Conditions Attacks

• Database Transactions and Locks: Use atomic operations and database-level locks to ensure no two requests can update critical resources at the same time.
• Idempotency: Make operations safe to repeat; don’t process the same action more than once for the same user/input.
• Re-check State: Always verify conditions (like stock levels or balances) at the very last second, just before committing changes.
• Rate Limiting: Slow down requests to sensitive endpoints to reduce the chance of concurrent exploitation.
• Testing Tools: Use Turbo Intruder, ffuf, or Race The Web to simulate attacks.

Conclusion

Race conditions are a hidden danger, often slipping through traditional security testing. Don’t let your application lose the race to an attacker! Always think about what could happen if two—or two thousand—users perform the same action at once. Code defensively, test aggressively, and remember:
It’s not just about speed. It’s about control.