IDOR and broken authorization
Two accounts is the test. Replay object IDs, hidden verbs, batch exports, and GraphQL node(id) as the other user. One account is guessing.
Skill: Access control and tenant boundaries
Ask: Can account A read or change an object that belongs to account B, including a job, export, or leftover endpoint?
Stop: One object you own is denied to the other account, and one object you should not own is not returned.
Practice the class in the browser: PortSwigger Web Security Academy. The lab is theirs. This page is the stop condition and the disclosures.
Checklists
- Authorization / IDOR - If you only have one account you are guessing. Two accounts is the test.
Disclosures
- A leftover trip endpoint returned another rider's driver details - Insecure direct object reference
- A GraphQL tag mutation acted on another user's asset - Insecure direct object reference
Playbooks
- IDOR & Broken Access Control - Systematically test whether one user can reach another user's objects or actions.
Tools
- Burp Suite - The industry-standard intercepting proxy for manual web testing. Community edition is free; Pro adds the active scanner and automation.
- Caido - A modern, lightweight web proxy and pentest toolkit - a fast alternative to Burp with a clean workflow and scriptable automation.
Payloads
- IDOR / object-ID canaries - Two-account object identifiers and verb swaps. Use records you created. The payload is the ID, not a dump.
Bypasses
- IDOR object and verb swap - Two accounts. Every verb. Hidden fields and batch IDs are the usual miss.
Questions
What if IDs are UUIDs?
UUIDs are still IDORs if you can obtain them from exports, websockets, search, or another object graph. Sequential is easier, not required.
GET is locked. Am I done?
Try PUT, PATCH, DELETE, and batch on the same object. Function-level authorization (BFLA) is the usual miss.
This page is the linked pack hunt_brief("idor") returns on the MCP connector. Authorized testing only.