Insecure Direct Object Reference (IDOR)

IDOR is when an application exposes internal objects (like user IDs, files, or records) in a way that lets users access data they shouldn’t, for example, by simply changing a value in the URL.

IDOR is one of the most common vulnerabilities found in bug bounty programs, probably “THE ONE” to know.

Example:
 
If a URL is 

https://example.com/profile?user_id=123

And the application doesn’t verify if the user accessing the page is actually user 123; someone could change the user_id to 456 and access that user’s profile and edit it.

IDOR is when you can access or modify data just by tweaking the URL or API request, and the system doesn’t check whether you should be allowed to.

Let’s say you’re logged in as a test user, and you spot a URL that end in :

orders/view/123

That number at the end might be your order ID. But what happens if you change it to:

orders/view/124

...and suddenly you're viewing someone else’s order? Maybe you can even delete or modify it. That’s an IDOR, a lack of proper access control.

It’s not just websites either. You can try the same thing in APIs using tools like Postman. Change the ID in the request and see if you can grab or update someone else’s data. If you can, it means there’s no access check, and that’s a critical security flaw.

IDOR can show up in many places, beyond changing IDs in URLs, but also in how files are stored and accessed.

Check the URL of the downloaded file.

E.g. it is possible to upload a CV to a job application website. The user can download the latest version to check for necessary updates.

A more advanced trick is to change the name of the previously uploaded file in the URL.
E.g. replace CV_John_Smith.pdf by CV_Peter_Jones.pdf.