An IDOR vulnerability is one of the most reliable classes of bug in bug bounty: common, high impact, and frequently missed by automated scanners because finding it needs human understanding of what an object should belong to. This post explains what an IDOR vulnerability is, how I hunt for it in authorised programs, and how to report it well.
What an IDOR vulnerability is
IDOR stands for Insecure Direct Object Reference. It happens when an application uses input you control, an ID in a URL, a parameter, a JSON field, to look up an object, but fails to check that you are actually allowed to access that object. PortSwigger describes it as an access-control weakness that arises “when an application uses user-supplied input to access objects directly” (PortSwigger).
The classic example: you view your invoice at /api/invoices/1043, change the number to 1044, and see someone else’s invoice. No exploit chain, no payload, just a reference the server trusted without an authorisation check. IDOR is a specific form of broken access control, which sits at the top of the OWASP Top 10:2025 as A01. In API terms it maps to Broken Object Level Authorization, consistently the number one API risk.
Horizontal, vertical and object-level
It helps to think in three flavours:
- Horizontal: accessing another user’s data at the same privilege level, your invoice becomes their invoice. The most common and easiest to demonstrate.
- Vertical: accessing something above your privilege level, a normal user reaching an admin-only object.
- Object-level on actions: not just reading but modifying or deleting another user’s object, which raises severity sharply.
How I hunt for IDOR
IDOR hunting is methodical. Recon gives you the endpoints (see my recon methodology); this is what I do with them.
Step 1: map every object reference
I proxy the application through Burp with two accounts logged in, and browse every feature as a normal user. In the proxy history I mark every request that carries an identifier: numeric IDs, UUIDs, usernames, email addresses, filenames, hashes. Anything that names an object is a candidate.
Step 2: swap references between accounts
With two test accounts I own (Account A and Account B), I take a request that legitimately accesses Account A’s object and replace the identifier with Account B’s. If A can read, change or delete B’s object, that is an IDOR. Using two accounts you control keeps the testing entirely within your own data and scope, never another real user’s.
GET /api/v2/users/1001/documents/5567 HTTP/1.1
Authorization: Bearer <Account-A-token>
# change 5567 to a document owned by Account B.
# if it returns B's document, that is a horizontal IDOR.Step 3: look past sequential integers
Developers often think switching from 1044 to a UUID fixes IDOR. It does not; it only makes the reference harder to guess. If the UUID leaks anywhere, in another API response, an email, a shared link, a referrer header, you can still abuse the missing authorisation check. So I hunt for places where one endpoint discloses the identifiers another endpoint fails to protect. That combination is a complete, high-quality finding.
Step 4: check every HTTP method
An endpoint might authorise GET correctly but forget PUT, PATCH or DELETE. Test each method the endpoint accepts. Write and delete IDORs are worth far more than read-only ones because the impact is concrete.
Step 5: the usual bypasses
When a direct swap is blocked, I try the techniques public write-ups document: supplying the ID in a different location (body versus query versus path), sending it as an array [1044], adding a duplicate parameter, changing content type, or wrapping the request through an export or share feature that may skip the main authorisation check. These are reconnaissance of the server’s logic, not exploitation of other users.
Where IDOR hides most
An IDOR vulnerability can appear anywhere an object reference meets a missing check, but over many programs some endpoints carry it far more often than others:
- Document, invoice, report and file download endpoints.
- User profile and settings APIs (
/users/{id}). - Multi-tenant or team features where a
team_idororg_idis trusted. - Mobile app APIs, which are often thinner on server-side checks than the web app.
- Export, share and “generate link” functions that run under elevated internal permissions.
Reporting IDOR well
A good IDOR report is almost self-proving. Include both accounts’ context, the exact request, and clear before-and-after evidence that Account A accessed Account B’s object. State the impact in business terms: “any authenticated user can read any other user’s invoices, exposing names, addresses and amounts.” Redact the actual data of your own test accounts to what is needed to prove it, and never include real third-party data. For writes, demonstrate the change on your own second account, not on anyone else’s.
How developers should fix it
Since this is published on a security site, the defence matters. The fix is always server-side authorisation on every object access: check that the authenticated principal owns, or has an explicit grant to, the specific object, on every request and every method. Do not rely on unguessable identifiers as the control, that is obscurity, not authorisation. Enforce it in a central layer, middleware or a shared policy function, so no individual endpoint can forget it, and add automated tests that attempt a cross-account access and expect a denial. That last step is what stops an IDOR vulnerability from quietly returning the next time someone adds a new endpoint.
Key takeaways
- IDOR is missing server-side authorisation on a user-controlled object reference.
- It is a form of broken access control, A01 in the OWASP Top 10:2025.
- Hunt with two accounts you own; swap references and test every HTTP method.
- UUIDs are not a fix if the identifier leaks elsewhere.
- Report with clear two-account before-and-after evidence and business impact.
- The fix is per-object authorisation enforced centrally.
Test your application for access-control flaws
IDOR and broader broken access control are among the first things I check in any assessment. If you want your web and API object-level authorisation tested properly, see my web application penetration testing and API penetration testing services, then get in touch.
