IDOR Explained: Insecure Direct Object References, with Examples

An insecure direct object reference (IDOR) is one of the simplest vulnerabilities to understand and one of the most damaging to find. It is also one of the most common in bug bounty reports. If you learn to test for one thing first, make it this.

What It Is

An application refers to an object, such as an invoice, a profile or a file, by an identifier in the request, and returns it without checking that the logged-in user is allowed to see it. Change the identifier, get someone else's data.

Simple Examples

• /invoice?id=1041 shows your invoice; /invoice?id=1042 shows another customer's
• An API call GET /api/users/58/address returns any user's address when the number changes
• A download link /files/report-2231.pdf works for anyone who guesses the number
• A form that updates a profile includes a hidden user ID, and changing it edits someone else's profile

Why It Is so Common

Developers often check that a user is logged in, but not that this user owns this object. The check must be written for every endpoint and every action, and one missing check is enough. Random-looking IDs make guessing harder but are not a fix: identifiers leak in URLs, emails and other responses.

IDOR and BOLA

In APIs the same flaw is called broken object-level authorization (BOLA), the first item in the OWASP API Security Top 10. In the web Top 10 it falls under broken access control, also number one; see the OWASP Top 10 explained.

How Testers Find It

• Create two test accounts, A and B, with their own data
• Use the application as A, recording every request in Burp Suite
• Replay A's requests with B's session, and swap object IDs between accounts
• Test every action: view, edit, delete, download, share
• Check IDs in paths, parameters, JSON bodies, headers and cookies

Use only test accounts and data you created. On bug bounty programs, stop at proof: do not browse real customers' records.

How Developers Fix It

• Check ownership or permission on the server for every object, on every request
• Derive the user from the session, never from a user-supplied ID
• Centralize authorization checks so they cannot be forgotten
• Write automated tests that try cross-account access

Learning Access-Control Testing

Our Application Security course teaches access-control testing systematically, with an endpoint and role coverage matrix in Burp Suite. Read bug bounty for beginners in India if you want to apply it on real programs.