Race Condition Lab: Redeem a One-Time Coupon Twice

This article explains race conditions through a practical lab where attackers redeem a single-use coupon twice by exploiting timing gaps in non-atomic code. It demonstrates how check-then-act patterns with separate read and write steps create windows where concurrent requests can slip through validation, and teaches defensive techniques to close those gaps. Race conditions in redemption and payment flows are a real, exploitable vulnerability class found regularly in bug-bounty reports.

• Check-then-act vulnerability patternThe lab demonstrates that DealStore's coupon redemption runs as three separate steps: read whether the coupon is used, apply the $10 discount if not, then mark it used. Because these are separate database operations, two simultaneous requests can both read 'unused' before either writes the 'used' flag, causing both to apply the discount.
• Concurrency exploits timing windowsThe attack works by preparing two identical redemption requests for the same order and firing them as close to simultaneously as possible. Both requests pass the 'is it unused?' check before either has written the used flag, allowing the discount to stack beyond the intended $10 limit. The vulnerability only manifests under concurrent timing—sequential requests never trigger it.
• Atomicity is the core defenseThe article emphasizes that validity checks and the updates enforcing them must happen as a single atomic operation. Three concrete defenses are offered: use a unique database constraint to reject duplicate writes, perform check and update in one atomic statement within a properly-locked transaction, or employ idempotency keys to collapse concurrent or repeated requests into a single effect.
• Real-world scope beyond couponsRace conditions in check-then-act flows enable tangible abuse across payment systems: double-spending gift cards, withdrawing balances multiple times, and claiming limited offers repeatedly. These concurrency bugs appear regularly in bug-bounty reports, typically classified under Business Logic or Broken Access Control vulnerabilities.
• Testing technique for vulnerability discoveryThe article recommends finding races in any application by identifying 'only once' actions—such as redeem, withdraw, vote, or claim—then firing several identical requests simultaneously. If more than one succeeds, the check and write operations are not atomic and the system is vulnerable.
• Why sequential testing misses the bugIf clicking the redeem button sequentially only ever applies the coupon once, developers may falsely conclude the logic is correct. True concurrency exposure only emerges when requests arrive at overlapping moments, making the vulnerability invisible during normal sequential testing.

Bottom line: Race conditions in check-then-act logic are exploitable, real-world vulnerabilities that allow attackers to bypass 'only once' constraints by timing concurrent requests to slip through validation gaps; defend by making the check and update atomic through database constraints, transactions with proper locking, or idempotency keys rather than relying on separate read-then-write operations.