Race Condition Vulnerabilities in APIs

What happens when an attacker sends 20 identical withdrawal requests to your payment API in the same millisecond? Without proper synchronization, every request could succeed, draining the account well beyond its actual balance.

Race condition vulnerabilities are among the most overlooked flaws in API security. Standard scanners miss them, and code reviews rarely flag them. Yet a single race condition attack can let bad actors redeem coupons hundreds of times or bypass rate limits entirely.

The Salt Labs State of API Security Report, 2024, found that 95% of organizations experienced security problems in production APIs, with 80% of attack attempts targeting weaknesses listed in the Open Web Application Security Project (OWASP) API Security Top 10. Business logic flaws, including race conditions, are a growing share of those incidents. For a full breakdown, see our guide to the 2023 OWASP API Top 10.

What Is a Race Condition Vulnerability?

A race condition in cybersecurity occurs when two or more operations access shared data simultaneously, and the outcome depends on which operation finishes first. In APIs, multiple HTTP requests hitting the same endpoint can exploit a gap between when the server checks a value and when the server updates that value.

Here is a race condition example using a Python Flask API that applies a one-time discount:

@app.route('/apply-coupon', methods=['POST'])

def apply_coupon():

    coupon = db.get_coupon(request.json['code'])

    if not coupon.used:          # Step 1: Check

        apply_discount(coupon)    # Step 2: Use

        coupon.used = True        # Step 3: Update

        db.save(coupon)

        return {"status": "Discount applied"}

    return {"error": "Coupon already used"}, 400

The flaw sits between Step 1 (check) and Step 3 (update). When an attacker fires 20 requests within milliseconds, multiple threads pass the "not used" check before marking the coupon as redeemed. One coupon, twenty discounts.

That pattern is called a Time-of-Check to Time-of-Use (TOCTOU) flaw, the most common race condition vulnerability in API security.

Why APIs Are Prime Targets for Race Condition Attacks

Web applications often serialize requests per session. APIs work differently, and several traits make race conditions far more likely:

• Stateless design. RESTful APIs treat every request independently. No session locking exists to serialize concurrent requests from the same user.
• High concurrency. APIs handle thousands of parallel requests. Each request spawns a separate thread, and all threads compete for shared resources like database rows.
• Microservices architecture. A single user action may trigger calls across multiple services, each with a separate state store, making synchronized updates extremely difficult.
• Asynchronous processing. Background jobs, message queues, and event-driven patterns introduce timing gaps that attackers can target.

Well-written API code can still harbor race condition vulnerabilities when concurrency is not handled at the data layer. Pairing concurrency controls with REST API security best practices provides a stronger foundation.

Real-World Race Condition Attack Patterns in APIs

Race condition attacks are not theoretical. Here are patterns that directly target API endpoints:

• Payment and balance manipulation. An attacker with $100 sends two simultaneous $80 withdrawal requests. Both read the balance as $100 before either deducts, resulting in $160 withdrawn.
• Coupon and promo code abuse. A single-use code is sent in rapid parallel requests. The API checks redemption status for each request before marking the code as used, letting attackers stack discounts far beyond the intended limit.
• Rate limit bypass. API rate limits relying on "check then increment" logic are vulnerable. Multiple requests arriving in the same race window all pass the check before the counter increments, bypassing brute-force protections.
• Account takeover via email verification. When a user changes an email, the API sends a verification token. If an attacker triggers a password reset in the exact same window, the reset token may route to the attacker's newly linked email.

Each pattern ties directly to the OWASP API Security Top 10 (2023), particularly API6:2023 (Unrestricted Access to Sensitive Business Flows) and API1:2023 (Broken Object Level Authorization).

How to Detect Race Conditions in APIs

Standard Dynamic Application Security Testing (DAST) scans rarely catch race conditions. Our API penetration testing checklist covers the full workflow, but here are the key detection methods:

• Parallel request testing. Tools like Burp Suite's Turbo Intruder support single-packet attacks, bundling multiple HTTP/2 requests into one TCP packet to eliminate network jitter and force tight race windows.
• Code review for TOCTOU patterns. Flag any check-then-act sequence on shared state without database-level locking. Common culprits include balance checks before transfers and token validation before redemption.
• Automated API security testing. Purpose-built API security testing platforms simulate concurrent request patterns across every endpoint, catching race conditions before flaws reach production.

5 Strategies to Prevent Race Condition Vulnerabilities

Use our API security checklist alongside these five strategies:

1. Use atomic database operations. Combine the check and update into a single statement:

UPDATE coupons SET used = TRUE

WHERE code = 'PROMO20' AND used = FALSE;

If zero rows are affected, the coupon was already redeemed. No race window exists.

2. Implement row-level locking. For multi-step logic, use SELECT ... FOR UPDATE to lock the database row until the transaction completes:

BEGIN;

SELECT balance FROM accounts WHERE user_id = 123 FOR UPDATE;

UPDATE accounts SET balance = balance - 80 WHERE user_id = 123;

COMMIT;

3. Require idempotency keys. Each state-changing request should include a unique key. The API stores the key and rejects duplicates, even when requests arrive simultaneously.

4. Apply optimistic concurrency control. Add a version column to database records. Every update must match the current version. A second concurrent request fails because the version already changed:

UPDATE orders SET status = 'confirmed', version = version + 1

WHERE id = 456 AND version = 3;

5. Integrate continuous API security testing. Race conditions often slip in through routine code changes. Running automated API security testing within a Continuous Integration/Continuous Deployment (CI/CD) pipeline ensures every release gets checked for concurrency flaws, business logic abuse, and the full OWASP API Top 10.

Protect Your APIs Before Attackers Exploit the Gaps

Race condition vulnerabilities hide in the gap between developer intent and concurrent execution. Atomic operations, proper locking, idempotency keys, and continuous testing close those gaps.

APIsec tests every API endpoint for business logic flaws, OWASP API Top 10 vulnerabilities, and real-world exploits.

Start a free scan and uncover what your current tools are missing.

FAQs

What is a race condition in cybersecurity?

A race condition occurs when multiple processes access shared data simultaneously without proper synchronization, allowing attackers to manipulate outcomes like duplicate transactions or bypassed access controls.

Can automated scanners detect race condition vulnerabilities?

Standard DAST scanners typically miss race conditions. Detecting TOCTOU flaws requires specialized concurrency testing that sends parallel requests and analyzes responses for inconsistencies.

What is the most common race condition example in APIs?

Coupon or promo code abuse is the most frequent pattern, where attackers send rapid parallel requests to redeem a single-use code multiple times before the API marks it as used.