IDOR is a form of broken authorisation in which an application exposes internal object references (such as record IDs, filenames, or account numbers) to users, and then fails to check that the user is authorised to access the referenced object.
A common example is a URL or API request that includes something like /invoice/12345 or user_id=17. If changing the value to 12346 or 18 returns another customer’s data, then the issue is not the predictable identifier itself, but the fact that the application relies on it for access control without proper server-side checks.
IDOR often appears in web and API applications where developers assume that hiding or obscuring identifiers in the interface, using UUIDs, or relying on client-side logic is enough. Even non-sequential identifiers like UUIDs can be harvested through enumeration or leaked in other ways, and if the server does not verify permissions then any valid identifier can be used to access data or functions that should be protected.
IDOR can expose personal data, invoices, support tickets, medical records, internal documents, or administrative functions. In business systems, it can also allow unauthorised state changes such as approving transactions, editing profiles, or cancelling services on behalf of other users.
This is a core focus area in both web application penetration testing and API penetration testing . In API security terminology, IDOR is often discussed in the context of “object-level authorization” or “insecure object references”. The key point is that access control must be enforced on the server side for every request, regardless of how the client identifies the target object.