---
{
  "title": "Insecure direct object references (IDOR)",
  "summary": "IDOR occurs when an application accepts a reference to an object without checking whether the caller may access that object.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Insecure Direct Object Reference Prevention",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

IDOR occurs when an application accepts a reference to an object without checking whether the caller may access that object. References include record IDs, filenames, UUIDs, and tokens. The defect is the missing authorization relationship rather than whether the reference happens to be easy to guess.

## A practical example

A learner requests a course receipt by its identifier. The server must query within that learner's permitted records instead of retrieving any receipt and assuming the caller owns it. Update and delete operations require the same resource-specific checks.

## What to check

Test with two users and objects belonging to each. Exercise read, modify, export, and delete endpoints, including nested resources and background jobs. Enforce policy at the data access boundary.

## A common pitfall

Replacing sequential numbers with UUIDs reduces guessing but does not establish authorization. A leaked or otherwise discovered reference can still expose the object.

## Think it through

A UUID is hard to predict. Is checking ownership still necessary?

**Answer:** Yes. Possession of an object identifier is not proof that the caller has permission to use it.

## Ownership is a relationship, not a naming rule

A fictional school stores certificates under random identifiers. Two learners each have a certificate, and administrators can access both for support. The authorization rule therefore involves the requesting identity, the requested certificate, and the permitted action. Comparing an identifier with the currently signed-in user's ID is not necessarily enough: the certificate has its own owner field and administrative access has a different policy.

Nested routes deserve attention. A path can contain a permitted course identifier followed by a certificate belonging to another course. Checking only the outer resource leaves the inner reference unresolved. Background exports introduce similar problems if a job receives an object ID but later processes it under a service account without preserving the original user's access scope.

A reference may also be intended as a capability, such as an explicitly designed temporary sharing link. That design needs sufficient unpredictability, a defined lifetime, restricted operations, and a way to withdraw access where required. It should be a deliberate sharing mechanism, not an accidental consequence of skipping ownership checks.

## Practice with a permissions table

Create two fictional learners, one support role, and separate training records. Write the expected read and update permissions before making requests. Test list, detail, download, and modification operations because they may use different code paths. Avoid using other people's real records as evidence.

When documenting a defect, distinguish an object being discoverable from an object being usable without permission. The former can increase exposure, while the latter is the core access-control failure. The repair should enforce the relationship consistently, and the regression check should preserve legitimate support access as well as blocking unauthorized learner access.

## Related concepts

- [[authorization]]
- [[broken-access-control]]
- [[multi-tenant-isolation]]