Beginner's guide to IDOR

What is an IDOR?

IDOR (Insecure Direct Object Reference) is one of the most common and most rewarded vulnerabilities in bug bounty programs. It happens when an application exposes a direct reference to an internal object — like a user ID, a filename or a database key — without checking that the user is authorized to access that resource.

In simple terms: if you can change a number in a URL or a request and access another user's data, you're probably looking at an IDOR.

Types of IDOR

Horizontal IDOR

The most frequent type. A user accesses resources belonging to another user at the same privilege level. For example:

GET /api/users/1234/profile    → Your profile
GET /api/users/1235/profile    → Another user's profile (unauthorized!)

Vertical IDOR

Happens when a user with low privileges accesses functions meant for a high-privilege user (for example, a normal user reaching an admin panel):

GET /api/admin/users           → Should only be accessible to admins
GET /api/admin/settings        → System settings

Function-based IDOR

It's not always about reading data. Sometimes you can perform actions on resources that aren't yours:

DELETE /api/posts/5678         → Delete another user's post
PUT /api/users/1235/email      → Change another user's email

How do you find IDORs?

1. Map every endpoint

Use Burp Suite to intercept every request as you browse the application. Pay special attention to any parameter that contains IDs, UUIDs, filenames or object references.

2. Spot suspicious parameters

Look for patterns like:

/api/v1/users/{user_id}/orders
/api/v1/documents/{doc_id}/download
/api/v1/invoices?id=12345
/profile?account=usuario123

3. Use two accounts

This is the most effective technique. Create two test accounts (Account A and Account B):

1. Log in with Account A and capture the requests
2. Copy the requests and replace the IDs with Account B's
3. Send the modified request with Account A's cookies/tokens
4. If you get Account B's data back, you have an IDOR

4. Parameter fuzzing

If the IDs are numeric and sequential, try Burp Intruder:

GET /api/users/§1§/profile HTTP/1.1
Authorization: Bearer your_token_here

Payload: Numbers, From 1 To 1000, Step 1

5. Try different ID formats

Sometimes the same endpoint accepts different formats:

/api/users/123          → Numeric ID
/api/users/user_123     → Prefixed ID
/api/users/abc-def-ghi  → UUID
/api/users/admin@test.com → Email as identifier

Common IDOR locations

• Profile endpoints: /api/users/{id}, /profile/{id}
• File downloads: /api/files/{file_id}/download, /documents/{name}.pdf
• REST APIs: CRUD operations on any resource
• Export functions: /api/export?report_id=123
• Messages and notifications: /api/messages/{id}, /api/notifications/{id}
• Transaction history: /api/transactions/{id}
• GraphQL endpoints: Queries that accept IDs as variables

Bypassing common protections

If the first attempt doesn't work, try these variations:

# Change the HTTP method
GET → POST, PUT, PATCH

# Add/remove parameters
/api/users/123 → /api/users/123?admin=true

# Change the ID format
123 → 0123 → 00123

# Encode the ID
123 → MTIz (Base64)

# Try the ID in different locations
Body, URL, Headers, Cookies

Tips for writing good reports

1. Describe the impact clearly: "An attacker can access the personal information (name, email, address) of any user on the platform"
2. Include detailed reproduction steps: Step by step, with screenshots
3. Show the full HTTP requests: Include headers, body and response
4. Prove it with two accounts: Show that Account A accesses Account B's data
5. Classify the severity correctly: An IDOR exposing bank data is not the same as one exposing public avatars

Recommended tools

• Burp Suite: To intercept and modify requests
• Autorize (Burp extension): Automates authorization testing
• FFUF: For fast endpoint fuzzing
• Postman: To organize and replay requests

Conclusion

IDORs are "simple" vulnerabilities in concept but extremely impactful. They're an excellent gateway into the bug bounty world because they don't require highly advanced technical knowledge, but they do require patience, methodology and attention to detail. Practice with lab platforms and you'll soon be reporting your first real bugs.