Ask any working bug bounty hunter which vulnerability class pays their rent most consistently, and a lot of them will say the same thing: IDOR. Not because it's exotic or hard to find — the opposite. It's because almost every application has one somewhere, and almost every developer makes the same mistake that causes it.
What IDOR Actually Is
Insecure Direct Object Reference happens when an application lets you access a resource — a user profile, an invoice, a private message — using an identifier you control, without properly checking whether you are allowed to see that specific resource. The classic example is a URL like /invoice?id=1042. If changing that number to 1043 shows you someone else's invoice, that's an IDOR.
It's not a flashy bug. There's no clever payload, no obfuscated JavaScript, no WAF to bypass most of the time. It's just a missing ownership check on the backend. That simplicity is exactly why it's so common — and why it's so easy for a hunter to overlook if they're only looking for "interesting-looking" bugs.
Where It Hides
IDOR isn't limited to obvious numeric IDs in URLs. It shows up in:
API endpoints that accept a user ID or object ID as a parameter, even when that parameter is buried in a POST body or a header instead of the URL. GraphQL queries where a client can request another user's node by ID. Sequential or predictable identifiers in mobile app API calls, which developers often assume are "hidden" simply because they're not visible in a browser URL bar. Even file downloads — an exported PDF or CSV that's fetched via a guessable filename or ticket number.
How Hunters Actually Find It
The workflow is almost always the same: create two test accounts, perform an action as account A that generates a resource with an identifiable ID (an order, a message, a document), then try to access that same resource while authenticated as account B. If account B can see it, read it, modify it, or delete it — you've found something.
The habit that separates hunters who find IDOR consistently from ones who miss it: testing every object reference, not just the ones that look sensitive. A "harmless" endpoint that lets you view someone else's notification preferences might not be the finding by itself, but it tells you the developer isn't checking ownership anywhere in that service — which means the sensitive endpoint nearby probably has the same problem.
Why It Keeps Happening
Ownership checks are boring to write and easy to forget, especially as an application grows and endpoints multiply across different services and teams. A check that exists on the main web app's /profile endpoint often doesn't exist on a newer internal API added six months later for the mobile app. IDOR is less a coding mistake and more an organizational one — nobody owns the responsibility of verifying that every new endpoint enforces access control consistently.
What This Means for You
If you're starting out in bug bounty, IDOR is one of the best places to build real, repeatable skill. It doesn't require deep exploit development knowledge — it requires patience, a systematic testing habit, and comfort using an intercepting proxy to manipulate requests. Genesis Vault's IDOR lab is built around exactly this: two accounts, a set of endpoints, and a goal of finding every place the ownership check is missing.