How to Find Race Condition Bugs in Bug Bounty Programs
A race condition happens when two things run at nearly the same time and the app’s checks get confused.
In bug bounty terms: the app checks a limit, then updates a balance — but two parallel requests both pass the check before either update finishes.
Quick takeaway: Find limited actions → send many parallel requests → compare final state vs expected limit → prove economic or privilege impact cleanly.
Where races love to hide
- Coupon / promo redemption
- Referral bonuses
- “Use once” invite codes
- Inventory purchases
- Like / vote / follow limits
- Transfer or withdraw endpoints
- File upload then scan workflows
A comfortable testing flow
1) Pick a scarce resource
Something that should happen once or N times.
2) Capture the request
Use Burp (or similar) and confirm the normal single-request behavior.
3) Send a parallel group
Tools like Turbo Intruder or Burp’s parallel send features help. Start with a small batch.
4) Measure the outcome
Did you redeem the coupon twice? Buy more stock than available? Trigger two welcome bonuses?
Reporting without drama
Show:
- Expected limit
- Parallel request count
- Final database-visible result (balance, order list, redemption count)
- Timestamps if helpful
Keep tests reversible when you can. Do not turn a race into accidental fraud against real users.
Fixes worth suggesting
- Atomic database constraints / transactions
- Idempotency keys
- Server-side locks for critical sections
- Re-check limits inside the same transaction that mutates state
Original Bugflare article. Study path pairs well with PortSwigger race condition materials. Authorized testing only.