Testing playbook · advanced
Race Conditions (single-packet attack)
Exploit small timing windows where the app checks-then-acts, to double-spend, bypass limits, or over-redeem.
Detection firstStop as soon as the evidence decisively supports or falsifies the hypothesis.
Every step requires authorization. Review side effects before running commands against a live system.
Find limit-bound actions
Coupons, gift-card redemption, withdrawals, vote/like, invite acceptance, 2FA/OTP submission - anything meant to happen 'once'.
Evidence checkpointSave the request or command, raw result, timestamp, target, and a negative control before continuing.
Fire in parallel
Use Burp Repeater's parallel 'send group' or Turbo Intruder's single-packet attack to deliver many requests within the same window.
Evidence checkpointSave the request or command, raw result, timestamp, target, and a negative control before continuing.
Confirm the overshoot
Prove state that shouldn't exist: balance below zero, coupon applied twice, more redemptions than allowed.
Evidence checkpointSave the request or command, raw result, timestamp, target, and a negative control before continuing.
Field notes
Common guidance
- The HTTP/2 single-packet attack removes network jitter - it's the reliable modern technique.
- Even 'idempotent' endpoints can race on the read-modify-write of a counter.
Related tools
Mapped workflow tools
Sources
References
Version history: normalized permanent page created 2026-08-20.