November 5, 2026

IDOR: The Vulnerability That Hides Behind a Simple Request

Understanding how small authorization mistakes can expose an application’s most sensitive data.

By Amjadrajawala

4 min read

There is something interesting about IDOR vulnerabilities.

Sometimes, you don't need a complicated payload, an unusual encoding technique, or an advanced exploitation framework to discover one.

You just need to understand how an application identifies its resources — and, more importantly, how it decides who is allowed to access them.

Imagine logging into an application and opening your profile:

GET /api/users/1042/profile HTTP/2
Host: example.com
Authorization: Bearer USER_A_TOKEN

The server returns your profile information.

Now, imagine changing 1042 to 1043.

GET /api/users/1043/profile HTTP/2
Host: example.com
Authorization: Bearer USER_A_TOKEN

The server returns another user's private information.

That small difference could represent a serious security vulnerability.

This is the fundamental idea behind Insecure Direct Object Reference (IDOR).

But there is much more to IDOR than changing an ID in a URL.

1. What Actually Makes IDOR Possible?

IDOR is an authorization vulnerability that occurs when an application allows a user to access or manipulate an object without properly verifying whether that user has permission to perform the requested action.

An object could be almost anything:

  • A user profile
  • An invoice
  • A private document
  • A support ticket
  • A payment record
  • An uploaded file
  • An order
  • An account setting

The important distinction is that authentication and authorization are not the same thing.

Authentication answers:

"Who are you?"

Authorization answers:

"Are you allowed to access this resource?"

An application might successfully authenticate a user but still fail to verify whether that user owns the requested object.

That is where IDOR becomes possible.

2. Understanding IDOR Through a Realistic Scenario

Consider an application with two registered users:

  • User A — Account ID: 1042
  • User B — Account ID: 1043

Both users can access their own invoices.

User A sends the following request:

GET /api/invoices/5001 HTTP/2
Host: example.com
Authorization: Bearer USER_A_TOKEN

The application returns invoice 5001.

However, User A notices that changing the invoice identifier gives access to another invoice:

GET /api/invoices/5002 HTTP/2
Host: example.com
Authorization: Bearer USER_A_TOKEN

If invoice 5002 belongs to User B and its contents are returned to User A without authorization, the application has an access control problem.

The issue isn't that invoice IDs are predictable.

The issue is that the server isn't properly checking ownership or access permissions.

Even an unpredictable identifier can be vulnerable if authorization is missing.

3. IDOR Is Not Limited to GET Requests

One common misconception is that IDOR only involves viewing another user's information.

In reality, authorization failures can affect different HTTP methods.

GET — Unauthorized data access

GET /api/users/1043/profile

Can one user retrieve another user's private information?

POST — Unauthorized resource creation

POST /api/users/1043/addresses

Can a user create resources under another user's account?

PUT — Unauthorized modification

PUT /api/users/1043/profile

Can a user modify information belonging to someone else?

DELETE — Unauthorized deletion

DELETE /api/documents/8002

Can a user delete a resource they do not own?

The HTTP method does not determine whether a request is vulnerable. The authorization decision does.

4. Where Should You Look for IDOR?

During web application and API testing, I pay particular attention to places where an application references a specific resource.

Some common locations include:

URL parameters

/account?id=1042
/profile/1042
/orders/5001

JSON request bodies

{
  "user_id": 1042,
  "document_id": 5001
}

Nested API endpoints

/api/users/1042/orders/5001
/api/accounts/2001/documents/8002

Headers and other request fields

X-Account-ID: 1042

These locations are useful testing candidates, not proof of vulnerabilities.

An identifier can be public without being insecure. What matters is whether the server enforces the correct access permissions.

5. My Approach to Testing IDOR

When testing an application within an authorized bug bounty scope, I prefer understanding the normal workflow before modifying requests.

A simple two-account testing approach can help establish whether authorization is properly enforced.

Step 1: Create two test accounts

Use accounts that you control.

  • Account A
  • Account B

Step 2: Identify a resource

Create a test document, invoice or another resource using Account B.

Step 3: Capture the request

Use Burp Suite Proxy or HTTP history to understand how the application accesses that resource.

Step 4: Test with Account A

Authenticate as Account A and request the resource belonging to Account B.

Step 5: Compare the responses

Check whether the application returns the resource, denies access, or provides only information that is intentionally public.

Step 6: Verify the impact

If unauthorized access is possible, establish exactly what information or functionality is exposed.

Always use test accounts and test data. Avoid accessing unrelated users' private information.

6. Don't Ignore UUIDs

Some developers believe that using UUIDs instead of sequential numeric identifiers makes IDOR impossible.

For example:

/api/documents/550e8400-e29b-41d4-a716-446655440000

This identifier is significantly harder to guess than a sequential number.

However, UUIDs are not authorization controls.

If a user obtains another user's UUID through an exposed link, application response, or another legitimate workflow, the server must still verify access permissions.

The correct security approach is authorization enforcement on the server side, regardless of the identifier format.

7. Why Some IDOR Testing Attempts Fail

Not every modified identifier will produce an IDOR.

There are several reasons:

  • The server checks resource ownership.
  • The resource is intentionally public.
  • The application uses relationship-based permissions.
  • The identifier is validated against the authenticated session.
  • The requested resource does not exist.
  • The application returns cached or generic responses.

Also, receiving HTTP 200 does not automatically prove unauthorized access.

Always inspect the response body and verify whether sensitive information or unauthorized functionality was actually exposed.

A meaningful finding needs evidence, not just an interesting status code.

8. How to Write a Strong IDOR Bug Bounty Report

Finding the vulnerability is only part of the process. Explaining its impact clearly is equally important.

A good report should include:

Title: Insecure Direct Object Reference Allows Unauthorized Access to Other Users' Invoices

Summary:

The application does not properly enforce object-level authorization when retrieving invoice records. An authenticated user can access an invoice belonging to another test account by changing the invoice identifier in the request.

Steps to Reproduce:

  1. Log in using Account B.
  2. Create a test invoice.
  3. Capture its invoice identifier.
  4. Log in using Account A.
  5. Send a request to retrieve Account B's invoice.
  6. Observe whether the application returns the invoice without verifying ownership.

Impact:

Depending on the exposed information, an attacker may gain unauthorized access to invoices containing private customer or financial information.

Evidence:

Include the original request, modified request and relevant response with sensitive information redacted.

A clear report helps the security team understand the vulnerability, reproduce it and evaluate its actual impact.

9. Final Thoughts

IDOR is often described as one of the simplest vulnerabilities to understand, but identifying its real impact requires more than changing an object identifier.

It requires understanding how an application manages users, resources, ownership and permissions.

When testing APIs, don't focus only on whether an endpoint responds successfully.

Focus on whether the authenticated user is actually authorized to perform the requested operation.

That difference is what separates ordinary request manipulation from meaningful security research.

Remember: An identifier tells an application which object you want. It should never be the only thing that determines whether you're allowed to access it.

This article is based on practical web application security concepts and authorized testing methodologies. All examples use fictional endpoints and test data.