Payloads.
Pick a vulnerability class, learn how to hunt it step by step, grab the payloads that actually work. Curated from PayloadsAllTheThings — the full section is linked under every class.
IDOR
Insecure Direct Object References — swapping an ID the server should have verified, accessing other users' data with your own session. The highest-frequency paid bug in bounty: no exploit skill needed, only systematic testing of every identifier.
Severity guide
High on any cross-user data read; critical for PII, financial records, and any write (modify/delete other users' objects).
Where to look
entry points to test first01
Everything with an ID
user_id, order_id, invoice_id, document UUIDs — every identifier in every request is a candidate.
02
API versions & mobile
v2/v3/mobile endpoints frequently miss the authorization checks v1 learned the hard way.
03
Bulk/export features
CSV exports, batch operations, webhooks — mass endpoints often skip per-object checks.
04
Secondary identifiers
Email, phone, username in request bodies — not just numeric IDs; any referenceable object can be swapped.
05
State-changing endpoints
DELETE/PUT/PATCH on other users' objects — worse than reads and commonly missed.
How to hunt it
in order, start to finishCreate two accounts
You need object A owned by account 1 and object B owned by account 2. Everything else is swapping references between them.
Swap the identifiers
user_id, order_id, document UUIDs — increment, or reuse B's value in A's session. A 200 with B's data is the bug.
Check every method and endpoint
GET often, but DELETE/PUT on someone else's object is worse. API v2/v3/mobile endpoints frequently miss the checks v1 has.
Guids aren't automatically safe
If a GUID leaks anywhere (email, export, another endpoint), it's still an IDOR — referencable = exploitable.
Automate the sweep
Burp Autorize replays every request as the second user and flags response differences — systematic coverage without manual repetition.
Chain for impact
IDOR on email change + password reset = full ATO; IDOR on invoice = PII leak. Find the highest-value object you can swap and report that chain.
Filter & validation bypasses
when your first tries get blocked- 01UUIDs used? Leak them first — email headers, exports, other endpoints, or predictable generation (timestamp-based UUIDv1).
- 02ID encoded/encoded? Base64/hex/rot13 wrappers decode trivially — decode, increment, re-encode.
- 03Server checks referrer? Replay without headers, or from a different client — referer checks are not authorization.
- 04403 on swap? Try the object's other endpoints (view vs edit vs delete), other API versions, or the mobile API.
Impact ladder
what makes it payable- 01Cross-user data access — PII, financial, medical records (critical).
- 02Account modification — change others' emails/phones, then reset their passwords.
- 03Full ATO — the chain from any object-write IDOR.
- 04Mass exposure — exports and bulk reads multiply the finding.
Payloads
3 · from PayloadsAllTheThingshttps://example.com/profile?user_id=124The canonical shape — change 124 to any other ID while logged in as yourself.
$user_id = $_GET['user_id'];The vulnerable pattern: the object comes from client input, not the session.
GET /api/v2/orders/1002 → GET /api/v2/orders/1003Sequential enumeration with your own session — the systematic sweep.
Payload strings, code and technical terms are shown in English on purpose — payloads must be copied exactly as published.
Payloads originate from PayloadsAllTheThings (MIT) — use them only on programs you're authorized to test.