How to Find IDOR Bugs: Step-by-Step Bug Bounty Checklist
IDOR (Insecure Direct Object Reference) is often the friendliest high-impact bug for newer hunters. You change an object ID. The server forgets to check ownership. Suddenly you see someone else’s invoice, message, or settings.
This checklist is meant to be used, not just read.
Quick takeaway: Two accounts → map IDs → swap ownership on GET and mutations → prove impact with redacted screenshots.
What “good IDOR” looks like
You stay logged in as user B, but you can read or change user A’s object.
That is broken access control — one of the most rewarded classes on bounty platforms.
The loop (do this every target)
1) Create two users
Always. One account cannot prove horizontal IDOR cleanly.
2) Collect object IDs
From Burp history, grab:
- Numbers and UUIDs in paths and JSON
- IDs inside export links and share URLs
- Nested IDs in request bodies
3) Swap ownership
For each interesting endpoint:
- Capture user A’s request with A’s object ID
- Replay with user B’s session and A’s ID
- Also try unauthenticated if the route looks public
4) Test more than GET
Mutations often pay more:
- Update
- Delete
- Share / ACL changes
- Download / export
5) Try boring format changes
18422vs"18422"- Arrays like
id[]= - GraphQL aliases / batch queries
Proving impact without making a mess
- Prefer reading non-sensitive fields first
- Redact PII in screenshots
- Show both user IDs and responses side by side
- State the role of each session clearly
Common traps
- Cache mix-ups (verify with unique content)
- Capability tokens that look like IDs (still test if leaked)
- “UUID means secure” (obscurity is not authorization)
Fixes to recommend
Server-side checks on every object access. Centralize policy. Add automated tests so user B always gets 403 on user A’s resources.
Original Bugflare article. Aligned with OWASP IDOR / broken access control guidance. Test only in-scope accounts and data.