When people start bug bounty, they often chase complex vulnerabilities. But in real-world programs, one vulnerability appears again and again — and causes serious impact.

That vulnerability is IDOR.

IDOR is simple to understand, easy to miss, and extremely dangerous when exploited correctly.

What Is IDOR?

IDOR (Insecure Direct Object Reference) occurs when an application:

  • Uses user-supplied identifiers (IDs)
  • Directly accesses backend objects
  • Without verifying whether the user is authorized to access them

In simple words:

If you can change an ID in a request and access someone else's data, that's IDOR.

What Does "Object" Mean Here?

An object is any backend resource, such as:

  • User profiles
  • Orders
  • Invoices
  • Tickets
  • Files
  • Messages
  • API resources

These objects are usually identified using:

  • Numbers (id=123)
  • User IDs
  • Account IDs
  • Order IDs
  • UUIDs

Whenever an application exposes these identifiers, authorization becomes critical.

A Simple Real-Life Analogy

Imagine an apartment building.

  • Your flat number is 101
  • Your key should open only flat 101

Now imagine you insert 102 into your key and the door opens.

That's IDOR.

The system never checked:

"Is this person allowed to access flat 102?"

A Basic IDOR Example

Consider this request:

GET /api/user/profile?id=101

The server returns your profile data.

Now you change the ID:

GET /api/user/profile?id=102

If the response returns another user's data, the application has failed to enforce authorization.

This is IDOR.

IDOR Is Not Limited to GET Requests

Many beginners assume IDOR exists only in URLs. That's a mistake.

IDOR can exist in:

  • GET requests
  • POST requests
  • PUT or PATCH updates
  • DELETE operations
  • Hidden parameters
  • Mobile app APIs

For example, a POST request like:

POST /api/order/view
{
  "order_id": "88991"
}

If changing order_id allows access to another user's order, IDOR exists — even though nothing is visible in the URL.

Why IDOR Happens (Root Cause)

The core problem behind IDOR is confusion between two concepts:

  • Authentication: Are you logged in?
  • Authorization: Are you allowed to access this resource?

Most vulnerable applications:

  • Verify that the user is logged in
  • But fail to verify ownership of the object

Logged in does not mean authorized.

Where IDOR Commonly Exists

IDOR is frequently found in:

  • User profile pages
  • Account settings
  • Order history pages
  • Invoice downloads
  • Support tickets
  • File download endpoints

A good rule to remember:

Wherever there is an ID, there is a chance of IDOR.

How to Find IDOR — Step-by-Step Approach

Finding IDOR is about logic, not tools.

Step 1: Identify Requests Using Object IDs

Look for:

  • URL parameters like id, user_id, account_id
  • IDs inside JSON bodies
  • Hidden form fields
  • API endpoints returning user-specific data

Burp Suite isextremely useful here.

Step 2: Change the Identifier Carefully

Modify the ID:

  • Increment or decrement it
  • Replace it with another valid ID
  • Use IDs from a different account (within scope)

Do not brute force blindly. Be methodical.

Step 3: Observe the Response

Pay close attention to:

  • Response body changes
  • Status code changes
  • Error messages vs successful data

If you receive valid data belonging to another user, IDOR is confirmed.

Step 4: Test Different Actions

Don't stop at read-only access.

Test whether you can:

  • View data
  • Modify data
  • Delete data

Privilege escalation through IDOR often has higher impact.

Why IDOR Is High Impact

A successful IDOR can lead to:

  • Exposure of personal data
  • Financial data leaks
  • Account takeover chains
  • Unauthorized actions
  • Business logic abuse

This is why IDOR findings often receive medium to critical severity in bug bounty programs.