What is an IDOR in an API?

An IDOR happens when an endpoint takes an object id and returns or changes that object without checking whether the caller is allowed to access that specific object. Authentication only proves who the caller is. The missing part is object-level authorisation against ownership, organisation, tenant, sharing, or role rules.

Why do generated CRUD endpoints often have IDOR risks?

Scaffolded CRUD usually knows how to map routes to tables and ids, then call the ORM by primary key. It does not understand your product’s permission model. Rules such as organisation membership, creator ownership, account hierarchy, support access, or feature roles have to be added explicitly in queries or service logic.

Do UUIDs prevent insecure direct object reference bugs?

UUIDs make object ids harder to enumerate, but they do not prove access. If a caller obtains a valid id through logs, another endpoint, a shared link, or a client-side leak, the same bug remains. The server still needs to constrain each object lookup to the caller’s allowed scope.

Permissions & Organizations

02.02 · Concept

The IDOR in Your API

Find the endpoints in your own codebase that fetch an object by id without checking who owns it, and say why a generated CRUD layer produces this by default.

IDOR is an object-level authorisation bug where an API accepts an id, loads the object, and trusts possession of the id as permission. Generated CRUD makes this easy because it can scaffold routes and primary-key lookups, but cannot know your tenant, ownership, sharing, or role rules.

What this lesson answers

how to find IDOR bugs in API code
why generated CRUD creates insecure object access
does using UUIDs fix IDOR vulnerabilities

Notes

An IDOR is what happens when an API accepts an object identifier, fetches that object, and returns or modifies it without proving the caller is allowed to access that particular object. The bug is not that ids are guessable, although sequential ids make discovery easier. The bug is that the server treats “I know the id” as equivalent to “I am allowed to use the id.”

The concrete mental model is: every endpoint that receives an id has two questions to answer. First, does this object exist? Second, does this authenticated user, organization, tenant, or role have permission to act on it? A safe…

References

Common questions

What is an IDOR in an API?: An IDOR happens when an endpoint takes an object id and returns or changes that object without checking whether the caller is allowed to access that specific object. Authentication only proves who the caller is. The missing part is object-level authorisation against ownership, organisation, tenant, sharing, or role rules.
Why do generated CRUD endpoints often have IDOR risks?: Scaffolded CRUD usually knows how to map routes to tables and ids, then call the ORM by primary key. It does not understand your product’s permission model. Rules such as organisation membership, creator ownership, account hierarchy, support access, or feature roles have to be added explicitly in queries or service logic.
Do UUIDs prevent insecure direct object reference bugs?: UUIDs make object ids harder to enumerate, but they do not prove access. If a caller obtains a valid id through logs, another endpoint, a shared link, or a client-side leak, the same bug remains. The server still needs to constrain each object lookup to the caller’s allowed scope.

Short definition: what is IDOR in Your API?

02.01 · Permissions & OrganizationsAuthentication Is Not Authorization 02.03 · Permissions & OrganizationsFine-Grained Authorization & ReBAC