Race Condition Testing
Core Posture
Treat race conditions as state-transition failures. Test whether two or more valid requests executed close together can bypass uniqueness, locking, idempotency, or workflow ordering.
Priority Patterns
- Value duplication: gift cards, coupons, credits, refunds, rewards, balances, and payouts.
- State transitions: activate email, verify phone, enable/disable MFA, delete member, follow/unfollow, invite accept, and account recovery.
- Approval and workflow state: pending-to-approved, duplicate payments, duplicate submissions, and job creation.
- Counter and relationship drift: likes, follows, comments, group members, referrals, and inventory.
- Client-side race: form callbacks, redirects, browser event ordering, and Safari/data URL oddities.
Assessment Loop
- Identify state-changing requests with uniqueness or one-time intent.
- Establish baseline before/after state and idempotency behavior.
- Send small synchronized bursts using identical or paired requests.
- Test cross-endpoint races: create/delete, redeem/refund, verify/change, invite/remove, enable/disable.
- Confirm durable duplicate value, forbidden state, inconsistent relationship, or bypassed one-time gate.
High-Value Cues
| Cue |
Ask |
| One-time token |
Can it be consumed twice? |
| Balance update |
Is check-then-update atomic? |
| State pair |
Can create/delete or enable/disable interleave? |
| Approval flow |
Can two transitions bypass final validation? |
| Background job |
Can duplicated jobs produce duplicated effects? |
Variant Playbook
- Send identical requests concurrently, then paired opposing requests.
- Race across web/API/mobile endpoints for the same action.
- Race token resend/use, old/new email verification, and MFA setup/verify.
- Race object deletion with action, membership removal with access, and payment failure with activation.
- Confirm database state, UI state, emails, notifications, and downstream jobs.
Confirmation Discipline
Strong evidence shows a durable state that cannot be produced sequentially. Rule out transient UI glitches, duplicate responses with one backend effect, and benign idempotent retries.
References
Read references/advanced-methodology.md only when the task needs deeper state modeling, concurrency variants, confirmation, impact ranking, or remediation checks.
1---2name: race-condition3description: Advanced race condition testing methodology for bug bounty and application security work. Use when testing or reviewing concurrent requests, double spending, duplicate redemption, multiple payout, email activation races, 2FA races, undeletable membership, follow/like counters, gift cards, coupons, balance changes, inventory, account state transitions, and workflows where simultaneous or reordered actions break locking, idempotency, or state consistency.4---56# Race Condition Testing78## Core Posture910Treat race conditions as state-transition failures. Test whether two or more valid requests executed close together can bypass uniqueness, locking, idempotency, or workflow ordering.1112## Priority Patterns1314- Value duplication: gift cards, coupons, credits, refunds, rewards, balances, and payouts.15- State transitions: activate email, verify phone, enable/disable MFA, delete member, follow/unfollow, invite accept, and account recovery.16- Approval and workflow state: pending-to-approved, duplicate payments, duplicate submissions, and job creation.17- Counter and relationship drift: likes, follows, comments, group members, referrals, and inventory.18- Client-side race: form callbacks, redirects, browser event ordering, and Safari/data URL oddities.1920## Assessment Loop21221. Identify state-changing requests with uniqueness or one-time intent.232. Establish baseline before/after state and idempotency behavior.243. Send small synchronized bursts using identical or paired requests.254. Test cross-endpoint races: create/delete, redeem/refund, verify/change, invite/remove, enable/disable.265. Confirm durable duplicate value, forbidden state, inconsistent relationship, or bypassed one-time gate.2728## High-Value Cues2930| Cue | Ask |31| --- | --- |32| One-time token | Can it be consumed twice? |33| Balance update | Is check-then-update atomic? |34| State pair | Can create/delete or enable/disable interleave? |35| Approval flow | Can two transitions bypass final validation? |36| Background job | Can duplicated jobs produce duplicated effects? |3738## Variant Playbook3940- Send identical requests concurrently, then paired opposing requests.41- Race across web/API/mobile endpoints for the same action.42- Race token resend/use, old/new email verification, and MFA setup/verify.43- Race object deletion with action, membership removal with access, and payment failure with activation.44- Confirm database state, UI state, emails, notifications, and downstream jobs.4546## Confirmation Discipline4748Strong evidence shows a durable state that cannot be produced sequentially. Rule out transient UI glitches, duplicate responses with one backend effect, and benign idempotent retries.4950## References5152Read `references/advanced-methodology.md` only when the task needs deeper state modeling, concurrency variants, confirmation, impact ranking, or remediation checks.
yafet-dev