An Insecure Direct Object Reference (IDOR) occurs when an application exposes internal object identifiers (IDs) and relies solely on the user to access only what they are supposed to. When the application does not enforce proper authorization checks, attackers can directly manipulate these identifiers to access or modify data that belongs to other users.

IDOR is one of the simplest and most dangerous access control vulnerabilities because it requires no special payloads—only changing a number, parameter, or filename can lead to data breaches or unauthorized actions.

How IDOR Works

Applications commonly reference objects using identifiers such as:

user IDs
order numbers
document IDs
invoice numbers
message IDs
file names
database record keys

Example vulnerable request:

GET /invoice?user_id=1001

If changing the parameter returns another user’s invoice:

GET /invoice?user_id=1002

then IDOR exists.

This happens because the application trusts user-supplied object references without verifying ownership or permissions.

Common IDOR Targets

IDOR often appears in:

user profiles
order histories
invoices and billing info
support tickets
messages and chats
file downloads
settings pages
project/task management endpoints
admin-controlled content
API endpoints

Any object linked to a user can become a target.

Practical IDOR Discovery Workflow

Step 1: Identify User-Controlled Object References

Look for parameters like:

?id=
?order_id=
?invoice=
?user=
?file=
?post=
?message=
?ticket=

Check values that appear numeric, sequential, or predictable.

Step 2: Change the Identifier Value

Example:

?id=10 → change to 11

If the response shows another user’s data, IDOR is confirmed.

Step 3: Test Horizontal Access Control

Horizontal access: same-level user accessing another user’s resources.

Examples:

User A views User B’s profile
User A reads User B’s messages
User A downloads User B’s files

Change identifiers:

/user/100 → /user/101

Step 4: Test Vertical Access Control (Privilege Escalation)

Vertical access: low-privileged user accessing admin-only functions.

Example:

/deleteUser?id=100

If a normal user can run admin operations, vertical IDOR exists.

Step 5: Inspect API Endpoints for IDOR

APIs often expose raw object identifiers:

GET /api/v1/orders/123
GET /api/v1/users/45/messages
GET /api/v1/files/1002/download

Change the ID and observe:

GET /api/v1/orders/124

If response differs, IDOR is present.

Step 6: Check JSON Body Injection

If the request body contains identifiers:

{
  "user": 1001,
  "file": 2003
}

Replace values:

{
  "user": 1002,
  "file": 2007
}

Applications often fail to validate these.

Step 7: Test Hidden or Disabled Functions

Sometimes hidden features are still available in the backend.

Example:

PATCH /user/1001?role=admin

If it works, IDOR allows privilege escalation.

Step 8: Analyze Response Codes and Behavior

Check for:

different data
missing authorization errors
file downloads with unexpected content
JSON objects belonging to other users

IDOR indicators include:

200 OK with unexpected data
302 redirect to a resource owned by another user
different file size or content

File-Based IDOR

Many apps use predictable filenames:

download.php?file=report_1001.pdf

Attacker tests:

download.php?file=report_1002.pdf

If accessible → unauthorized file access.

URL Path IDOR

RESTful APIs often embed IDs in paths:

GET /orders/10

Manipulate:

GET /orders/11

REST endpoints are frequently vulnerable due to simplified design.

Mass Assignment IDOR

Some frameworks automatically bind request fields to object attributes.

If the client includes extra fields:

{
  "user_id": 1,
  "role": "admin"
}

And the application applies it, this leads to privilege escalation through IDOR.

Cookie-Based IDOR

If cookies store user identifiers:

user_id=1001

Changing the cookie value:

user_id=1002

may expose other users’ data if no server validation occurs.

Practical Tools for Identifying IDOR

Burp Suite

Use:

Proxy → observe parameter patterns
Repeater → modify IDs and resend
Intruder → automate ID enumeration

Browser DevTools

Modify:

hidden inputs
JSON values
JavaScript variables

Custom Wordlists

Automate:

1001 → 2000
1002 → 2000

Small changes often reveal huge data leaks.

Advanced IDOR Techniques

Non-Numeric ID Manipulation

IDs may be:

UUIDs
hashed IDs
encoded IDs (base64, hex)

Decode base64:

dXNlcjEwMDI= → user1002

Modify and re-encode.

Guessing File/Object Paths

Try patterns:

/files/user_1/
/files/user_2/

Timestamp-Based Guessing

Some IDs use timestamps:

1678293848

Increment by seconds or minutes.

Testing Soft-Deleted Data

Deleted objects often still exist:

/invoice?id=100 → deleted  
/invoice?id=101 → active

Try older IDs.

Why IDOR Happens

IDOR exists because developers rely on:

client-driven identifiers
predictable IDs
trusting hidden fields
no server-side permission checks
insecure REST designs
convenience over authorization logic

Developers assume users will only access their own references—incorrectly.

Impact of IDOR

IDOR can lead to:

exposure of personal data
reading private messages
downloading confidential files
accessing financial information
modifying other users’ data
deleting or updating records
impersonation
privilege escalation
full account takeover

IDOR is extremely dangerous because it bypasses authentication without requiring complex input.

Intel Dump

IDOR allows direct access to objects by manipulating references such as IDs, filenames, or paths.
Occurs when applications trust user-supplied identifiers without verifying permissions.
Testing involves changing numeric, encoded, or structured IDs to access other users' data.
Appears in URLs, form fields, cookies, JSON bodies, and API endpoints.
Enables horizontal privilege abuse (accessing other users’ data) and vertical privilege escalation (acting as admin).
Impact ranges from data leaks to full account and system compromise.