IDOR

An Insecure Direct Object Reference (IDOR) happens when an application exposes a direct reference to an internal object — like a database ID in a URL — without properly checking whether the current user is actually allowed to access that specific object. It’s one of the simplest vulnerabilities to understand, and one of the most common findings in real bug bounty programs.

A Simple Example

Imagine a web app where viewing your own invoice looks like this:

GET /invoices/8421

If the application only checks “is this user logged in,” but never checks “does invoice 8421 actually belong to this user,” then simply changing the URL to /invoices/8422 could show a completely different customer’s invoice. No hacking tools required — just changing a number in the address bar.

Where IDOR Commonly Shows Up

• Sequential IDs in URLs (/user/105/profile, /order/2291)
• API endpoints that return data based on an ID parameter without an ownership check
• File download links referencing internal file IDs or paths
• Admin panels where role checks exist on the page, but not on the underlying API calls

How Defenders Fix It

• Server-side authorization checks on every request — always verify the logged-in user actually owns or has permission for the specific object being requested, not just that they’re logged in at all
• Indirect references — using non-guessable, random identifiers (UUIDs) instead of sequential integers, making it harder to enumerate other users’ objects (this alone isn’t a fix, but reduces trivial exploitation)
• Consistent authorization middleware applied to every endpoint, not just the ones a developer remembered to protect
• Automated testing that specifically tries accessing other users’ resources with a different account’s session