IDOR (Insecure Direct Object Reference)
IDOR is an access-control flaw where an application exposes a direct reference to an internal object (a database ID, a filename) and does not verify the user is authorised for it, so manipulating the reference reveals other data.
What it is
IDOR is an access-control flaw where an application exposes a direct reference to an internal object (a database ID, a filename) and does not verify the user is authorised for it, so manipulating the reference reveals other data.
Why it matters
IDOR is one of the most common and highest-impact web and API bugs, and it maps closely to BOLA in APIs. It is easy to introduce and easy to miss in review.
How we test it
We enumerate object references a role can see, then attempt to read or change references belonging to other users and roles, confirming server-side authorisation rather than UI hiding.
Common mistakes
- Hiding a link in the UI but leaving the endpoint open
- Using sequential IDs and assuming they are secret
- Enforcing access only on read, not on update or delete
An example
Changing ?doc=5012 to ?doc=5013 downloads another customer’s contract.
Not to be confused with
IDOR is the web-wide name; BOLA is the API-specific case in the OWASP API Top 10.
Related at PoCForge
Sources
Need this tested on your systems?
Share your scope and we will propose a human-led plan with proof and a retest.