Finding and Exploiting IDOR Vulnerabilities

Insecure Direct Object References (IDOR) remain one of the most common and impactful vulnerabilities in web applications. They occur when an application provides direct access to objects based on user-supplied input without verifying if the user is authorized to access those objects.

Why IDORs Are Still Everywhere

IDORs persist because they are logic errors, not syntax errors. Automated scanners struggle to find them because a request might be technically “valid” (return a 200 OK) even if it’s unauthorized. It requires a human to understand that “User A should not see User B’s photo”.

Step 1: Identify Potential IDOR Areas

Look for any feature where you interact with a specific data item:

• URL Parameters: /user/profile?id=123
• REST APIs: GET /api/orders/555
• POST Body: {“user_id”: 123, “email”: “…”}
• Headers: sometimes custom headers like X-User-ID.

Key areas: User Profiles, Order History, Messages/DMs, Document Downloads, Shipping Addresses.

CBBHWant to practise this hands-on? Certified Bug Bounty Hunter covers it with live labs and mentor support.

Step 2: Capture and Analyze Requests

Use Burp Suite to intercept traffic while browsing the application normally. Watch the HTTP History. Identify where the application uses identifiers to retrieve data. Are the IDs incremental numbers (101, 102), GUIDs/UUIDs, or usernames?

Step 3: Manual ID Manipulation

The classic test:

1. Create two accounts: Attacker and Victim.
2. Login as Victim and find an object ID (e.g., Order #500).
3. Login as Attacker.
4. Trigger a request for the Attacker’s object (e.g., Order #501).
5. Intercept the request in Burp. Change the ID from #501 to #500 (Victim’s ID).
6. Forward the request. If you see the Victim’s order details, you found an IDOR.

Step 4: Horizontal vs Vertical Testing

• Horizontal Privilege Escalation: Accessing data of a peer user (User A accessing User B).
• Vertical Privilege Escalation: Accessing data of a higher-privilege user (User accessing Admin data). Always try to change IDs to lower numbers (1, 0) to potentially hit Admin accounts.

Step 5: API-Focused IDOR Hunting

In REST APIs, methods matter. Even if GET /users/123 is secure:

• Try PUT/PATCH /users/123 to see if you can modify data.
• Try DELETE /users/123 to see if you can delete the object.
• Developers often protect the “View” (GET) but forget the “Edit” or “Delete” actions.

Step 6: Multi-Step IDORs

Sometimes the ID is a GUID/UUID which is hard to guess. Look for “Leaky” endpoints. Does the /search-users endpoint return the UUIDs of other users? If you can find a way to discover the UUIDs, you can then try the IDOR attack using those leaked IDs.

Step 7: Tools for Automation

While manual testing is best, tools help verify at scale:

• AuthMatrix (Burp Extension): Perfect for defining roles (User A, User B, Admin) and automatically replaying requests to check authorization across all of them.
• AutoRize: Another Burp extension for authorization testing.

Step 8: Bypass Protections

If the server blocks the request, try simple bypasses:

• Parameter Pollution: ?id=123&id=456 (Server might check the first but return the second).
• Type Juggling: Send ID as a JSON array or object instead of an integer. {“id”: [123]}
• Method Swapping: Change POST to GET or GET to POST.
• Extension Adding: /file/123.json instead of /file/123.

Step 9: Validate Impact

To get paid, you must show impact. Does the IDOR allow you to:

• Read PII (Personally Identifiable Information)?
• Modify critical data (Change email, password)?
• Perform actions on behalf of the victim?

Step 10: Write Reports

Clearly state the IDs of the Attacker and Victim used in your proof of concept. Explain the business impact. “I can read any user’s private messages” is a P1 (Critical) bug. “I can read a public profile via IDOR” is likely N/A.