What Is IDOR? Insecure Direct Object Reference Explained

What Is IDOR (Insecure Direct Object Reference)?

Insecure Direct Object Reference (IDOR) is an access control vulnerability in which an application exposes or accepts a reference to an object without properly verifying that the requester is authorized to access or modify that specific object. IDOR occurs when a user-controlled reference—such as a numeric ID, UUID, account number, filename, slug, token, database key, or other resource identifier—is used to select an object, but the server does not enforce the correct object-level authorization check. IDOR is therefore not caused simply by placing an ID in a URL. Direct object references are common and often necessary. The vulnerability exists when the application trusts the supplied reference without confirming that the current user is permitted to perform the requested action on the referenced resource.

How Does an IDOR Vulnerability Work?

An IDOR vulnerability works when an authenticated user changes a reference to an application object and the server accepts the new reference without checking whether that user is authorized to access or modify the referenced object.

A typical IDOR attack follows these steps:

1. The user accesses an object they are legitimately allowed to use:
   For example, a logged-in customer opens their own invoice, order, profile, document, or API resource.
2. The application exposes or sends an object reference:
   The request contains a value that identifies the resource, such as a numeric ID, UUID, account number, filename, slug, or API object identifier.
3. The requester changes the object reference:
   The user replaces their own object identifier with the identifier of another object while keeping the same authenticated session.
4. The modified request is sent to the server:
   The server resolves the new identifier and finds the referenced object.
5. The server fails to enforce object-level authorization:
   It verifies that the user is logged in, or simply retrieves the object, but does not verify whether that user is allowed to access or perform the requested action on that specific resource.
6. The unauthorized action succeeds:
   The application may return another user’s data or allow the requester to update, delete, download, share, or otherwise act on an object they should not control.

For example, a customer may legitimately access:

GET /api/invoices/4812

If they change the reference to:

GET /api/invoices/4813

and invoice 4813 belongs to another customer, the server should reject the request. If it returns the invoice because it checked only that the requester was authenticated and not whether they were authorized for invoice 4813, the endpoint is vulnerable to IDOR.

IDOR Vulnerability Example

A simple IDOR example is an invoice page that loads a record based on an identifier in the request but checks only whether the requester is logged in.

Suppose User A legitimately opens this resource:

/account/invoices/4812

Invoice 4812 belongs to User A. If the application also returns invoice 4813 after the reference is changed, even though invoice 4813 belongs to User B, the server has failed to enforce object-level authorization.

The important sequence is:

Authentication succeeds → object lookup succeeds → ownership or permission check fails or never occurs → unauthorized object is returned.

IDOR is not limited to reading data. The same failure can affect state-changing operations. For example, an update request that accepts an order or project ID may allow one user to modify another user’s resource if the backend does not validate ownership or permission before applying the change.

Where Can IDOR Vulnerabilities Appear?

IDOR can appear anywhere user-controlled data identifies an application object, not only in sequential numbers placed in URLs.

That means a UUID can be a direct object reference just as easily as the number 123. The identifier format changes how easy an object is to discover; it does not determine whether access is authorized.

IDOR vs BOLA: What Is the Difference?

IDOR and BOLA describe closely related object-level authorization failures, but BOLA is the broader API-security term. IDOR traditionally describes insecure direct references in web applications and APIs, while Broken Object Level Authorization focuses on whether an API enforces authorization whenever a client supplies an object identifier.

An IDOR is therefore a common way BOLA manifests in an API: the client supplies an object reference, the API resolves it, and the API fails to verify whether the caller is allowed to perform that action on the object.

OWASP notes that API object identifiers can be sequential integers, UUIDs, or generic strings and may appear in a request path, query string, header, or payload. Regardless of identifier type, the server still needs to authorize the requested object-level action.

Do UUIDs Prevent IDOR?

No. UUIDs can make object identifiers harder to guess, but they do not prevent IDOR because authorization must still be enforced independently.

A sequential ID such as 4812 may be easy to enumerate. A UUID is much harder to guess. That can reduce opportunistic discovery, but an identifier can still be exposed through links, application responses, logs, shared objects, browser history, APIs, client-side state, or other workflows.

The rule is simple: identifier secrecy is defense in depth; authorization is the security boundary.

How to Find IDOR Vulnerabilities

Find IDOR by identifying object references and verifying whether the server rechecks authorization when the user, role, tenant, object, or requested action changes. The safest and most reliable approach uses authorized test accounts and known test objects so the expected access policy is clear.

1. Identify object references: Review URL paths, query parameters, form fields, hidden inputs, JSON bodies, request headers, filenames, and API resource identifiers.
2. Define the expected authorization rule: Determine who should be allowed to read, update, delete, share, approve, export, or administer each object.
3. Use controlled identities: Create test users that represent different owners, roles, teams, and tenants so access decisions can be compared safely.
4. Change only the object reference: Keep the request otherwise comparable and verify whether the server reevaluates authorization for the newly referenced resource.
5. Test actions separately: A correct read check does not prove that update, delete, export, share, or administrative operations are protected.
6. Confirm the resource is actually restricted: Public or intentionally shared objects should not be reported as IDOR simply because another user can access them.
7. Check tenant boundaries: In SaaS applications, verify that users cannot cross organization or workspace boundaries even when they know a valid object identifier.

For APIs, start from a complete endpoint inventory and known authorization model. ScanTitan’s guide on how to scan an API for vulnerabilities explains why API testing needs specifications, authenticated context, methods, headers, and request bodies rather than ordinary website crawling alone.

How to Prevent IDOR

Prevent IDOR by enforcing server-side object-level authorization for every requested object and every operation before the application reads, modifies, deletes, exports, shares, or acts on that resource. Do not rely on hidden IDs, front-end restrictions, unpredictable URLs, or the fact that a user is already authenticated.

1. Enforce Object-Level Authorization on Every Request

Every sensitive object request should evaluate the current actor, the target object, and the requested action. A user who is allowed to read one invoice should not automatically be authorized to read all invoices, and permission to view an object should not automatically grant permission to update or delete it.

Authorization must be enforced in trusted server-side code or a server-side policy layer. Hiding a button, removing a link, or filtering objects only in client-side JavaScript does not prevent a direct request from reaching the backend.

2. Scope Object Queries to Authorized Resources

Where possible, retrieve objects through the set of resources the current user or tenant is already allowed to access rather than looking up any object globally and trusting that the request is legitimate.

find requested object within current user's permitted resources

OWASP’s IDOR prevention guidance recommends this scoped-query approach because it makes the authorization relationship part of the data-access path.

3. Centralize Authorization Policies

Use reusable framework policies, middleware, authorization services, or domain-level access-control components instead of scattering permission checks across many controllers and endpoints. Centralization reduces the chance that one new route or API method omits a required object-level check.

4. Deny Access by Default

When the application cannot establish that an actor is permitted to perform an action on an object, deny the request. Access should be granted through explicit policy, not inferred from possession of a valid identifier.

5. Enforce Tenant and Ownership Boundaries

Multi-tenant applications need to validate more than user identity. The server should confirm that the object belongs to a tenant, organization, workspace, or customer context the current user is permitted to access.

A valid relationship often looks like user → role or membership → tenant → object → allowed action.

6. Authorize Every Object Action Separately

Do not assume that one authorization check covers an object’s full lifecycle. Read, update, delete, share, export, approve, transfer, and administrative actions can require different permissions. A secure GET handler does not prove that PATCH or DELETE applies the same policy.

7. Use UUIDs or Random References Only as Defense in Depth

Complex identifiers can reduce enumeration and make bulk guessing less practical, but they should be added after authorization is correct. The backend must make the same access decision whether the identifier is 42, a UUID, a slug, or an opaque storage key.

8. Test Authorization Continuously

Include negative authorization cases in unit and integration tests: users should be tested not only for what they can access, but also for what they must be denied. API security testing should use identities from different roles and tenants and retest access-control rules after changes to routes, policies, object ownership, or authentication flows.

For broader testing methodology, see ScanTitan’s guide to API security testing.

GET    /api/projects/{id}
PATCH  /api/orders/{id}
DELETE /api/documents/{id}

Can Vulnerability Scanners Detect IDOR?

Vulnerability scanners can detect some IDOR patterns, but IDOR is difficult to confirm automatically because correct authorization depends on relationships between users, roles, tenants, objects, and allowed actions.

A scanner may see a 200 OK response after an object identifier changes, but status code alone cannot answer the business question: “Should this user have been allowed to access this object?” High-confidence testing therefore needs authenticated context and, for many applications, more than one identity.

How Strong Is the Evidence for an IDOR Finding?

Because meaningful IDOR testing usually happens behind login, an authenticated scan can reach routes and API operations that an anonymous scan cannot. Complex authorization still benefits from human validation, which is one reason vulnerability scanning and penetration testing remain complementary.

ScanTitan’s Website Vulnerability Scanner can test web applications and APIs for runtime security weaknesses and authenticated attack surface, while deeper multi-user authorization logic may require additional manual validation.

Authentication vs Authorization vs IDOR

Authentication verifies identity, authorization determines permissions, and IDOR is an authorization failure involving access to a specific object through a controllable reference.

This distinction matters because many IDOR vulnerabilities exist in applications with perfectly functional login systems. The user is correctly authenticated; the failure happens afterward when the server decides what that authenticated identity may access.

Frequently Asked Questions