IDOR, or Insecure Direct Object Reference, is when an app uses an id from the request to fetch a record but never checks that the record belongs to the requesting user. By changing the id, for example /invoice/123 to /invoice/124, an attacker reads or edits someone else's data. It is a failure of authorization, not authentication.
Why it is so common
The straightforward way to build an endpoint is take the id, look it up, return it. That works and demos perfectly. The missing step, confirm this record's owner is the current user, is not required for the feature to function, so it is easy to leave out and hard to notice.
How to prevent it
Every lookup by id must be scoped to the caller: either filter the query by the authenticated user's id, or fetch and then verify ownership before returning. Using unguessable ids helps a little but is not a fix, because the real problem is the missing ownership check.
What this means for AI-generated code
IDOR is one of the most common serious issues in AI-built apps, because assistants generate the fetch-by-id endpoint without the ownership check. Any logged-in user can then walk through ids and read data that is not theirs.
Common questions
What is the difference between IDOR and BOLA?
They describe the same vulnerability class. IDOR (Insecure Direct Object Reference) is the original OWASP name. BOLA (Broken Object Level Authorization) is the current OWASP API Security Top 10 terminology. Both mean: the endpoint fetches a resource by id without verifying the caller owns it.
Do UUIDs instead of sequential IDs prevent IDOR?
They make guessing harder but do not fix the underlying problem. An attacker who can observe any id (from their own requests, from a link, from another exposure) can use it against another user's account. The fix is the ownership check in the query, not the unpredictability of the id.
How do I test my own API for IDOR?
Create two accounts. Log in as user A and collect ids from your own data (order numbers, document ids, profile ids). Then while still authenticated as user A, make requests using user B's ids. If you get a 200 response with user B's data, you have an IDOR. Any endpoint that accepts an id and returns a record without a scope check is a candidate.