Race Conditions Testing and Exploitation Playbook

Problem

Race conditions often appear in non-atomic read-then-write flows: two requests read stale state in sequence and then both submit changes based on that stale state. This can cause duplicate one-time rewards, bypassed balance checks, or duplicate ledger rows. This skill frames race conditions as authorization and state-integrity issues, not merely concurrency-performance concerns. It is useful for reviewing one-time operations, coupons, inventory deduction, and reward issuance.

How It Works

The core approach is to trigger requests in parallel and then collect application-layer evidence:
- Use HTTP/1.1 last-byte sync, HTTP/2 single-packet, or Turbo Intruder gates to make multiple requests arrive together;
- Prefer one-time or balance-like operations as test points;
- Compare abnormal results such as duplicate success responses, inconsistent balances, or duplicate ledger rows;
- For business-rule cases, combine the findings with business-logic-vulnerabilities to reason about the full flaw chain.

Boundaries

The material stresses authorized testing only. Do not launch parallel requests against production services without permission. If the target is an ordinary state update, first confirm that the business logic actually depends on the earlier stale read.