Insecure direct object reference is an access-control failure where an application exposes object identifiers without enforcing whether the requester should be allowed to use them.
Insecure direct object reference, usually called IDOR, is an access-control failure where an application exposes object identifiers without enforcing whether the requester should be allowed to use them. In plain language, the application trusts a record ID, file ID, or similar reference without properly checking ownership or permission.
IDOR matters because many applications expose identifiers naturally through URLs, APIs, and forms. If the application relies too heavily on the identifier itself instead of checking who should be able to use it, sensitive data or functions may be exposed.
It also matters because the underlying flaw is often simple: the system verifies that the user is signed in but not that the user is authorized for that specific object.
IDOR appears in APIs, document portals, customer dashboards, workflow systems, and multi-tenant applications. Teams connect it to Broken Access Control, Authorization, Role-Based Access Control, and API Security.
It is best understood as one common pattern inside the broader access-control problem family.
A user opens a customer portal request and notices the API call includes a numeric document ID. If changing that ID returns another customer’s file because the server never checks ownership, the application has an IDOR-style access-control weakness.
IDOR is not the same as failed Authentication. The user may be fully authenticated; the problem is that object-level authorization is missing or weak.
It is also not always a separate category from Broken Access Control. In practice, IDOR is one of the clearest examples of broken access control.