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.