You log in as user #1001. You change the URL to user #1000. Suddenly, you're looking at someone else's invoices, emails, and phone numbers. No hack, no injection — just a missing access control. Welcome to the world of IDOR, one of the most rewarding bug bounty findings.

Free Link

Welcome back to the Bug Bounty Bootcamp. You've exploited complex vulnerabilities like SQL injection, XSS, and file upload RCE. Now, we tackle something deceptively simple yet incredibly common: Insecure Direct Object Reference (IDOR) . This isn't about breaking syntax or bypassing filters. It's about asking the server for something you shouldn't have — and the server just handing it over. IDOR vulnerabilities arise when an application uses user-supplied input (like an ID in a URL or API request) to directly access an object (a profile, an order, a document) without verifying that the requesting user actually owns or has permission to access that object. The fix is often a single line of authorization logic. But when that line is missing, the results can be catastrophic.

The Classic IDOR: A Numerical ID in the Wild

Imagine you're on a banking or e-commerce site. You navigate to your profile settings. The URL looks like this: https://example.com/api/user/167865

The response returns:

{
  "id": 167865,
  "username": "nahomsegu",
  "address": "123 Main St",
  "phone": "555-1234"
}

Now, what happens if you change the ID to 1? https://example.com/api/user/1

If the response now shows "username": "admin" and their address and phone number, you've found an IDOR. The server fetched the object with ID 1—the admin's record—without checking that you are allowed to see it.

The Hunter's Reflex: Whenever you see a numerical ID in a URL, API endpoint, or even a hidden form field, test variations. Increase by one. Decrease by one. Try zero. Try negative numbers. Try random high numbers. You'd be surprised how often this works.

Beyond GET: IDOR in POST, PUT, and DELETE

IDOR isn't limited to reading data. You can often modify or delete other users' information.

Scenario: An API endpoint for updating a profile uses a PUT request with a JSON body:

PUT /api/user/profile
{
  "id": 167865,
  "username": "nahomsegu",
  "email": "nahom@example.com"
}

If you change the id to 1 and the email to your own address, you might successfully update the admin's email. Then you could request a password reset and take over the account. The server never verified that the id in the request body belongs to the authenticated session.

The Hunter's Checklist for IDOR:

• Read operations: GET requests with IDs in URL parameters or path.
• Write operations: POST, PUT, PATCH, DELETE requests with IDs in the body or URL.
• Bulk operations: Endpoints like /api/orders/export?user_id=... or /api/messages?thread_id=...
• File access: /download?file_id=... or /images/user_1234_avatar.jpg

The Two-Account Method: The Gold Standard for Testing

The safest and most reliable way to find IDOR is to create two accounts on the target application.

1. Account A (Attacker): Log in on Browser 1 (e.g., Chrome).
2. Account B (Victim): Log in on Browser 2 (e.g., Firefox Incognito).
3. Capture IDs: From Account B, note the user ID, order ID, document ID, or any object identifier. From Account A, capture the same type of ID.
4. Test with Account A: While logged in as Account A, try to access Account B's objects by changing the ID in requests (using Burp Suite or browser DevTools).
5. If successful: You have proof that Account A can access Account B's data without authorization.

Why this method is preferred: You never access a real, unrelated user's data. You only test between your own two accounts, which is ethical and within most bug bounty policies.

When IDs Aren't Sequential: UUIDs and Hashed Identifiers

Modern applications often use UUIDs (Universally Unique Identifiers) like 550e8400-e29b-41d4-a716-446655440000 instead of sequential integers. These are not guessable by simple incrementing. However, IDOR can still exist.

The Challenge: You can't brute force a 128-bit UUID space. But you might not need to.

Leakage Vectors:

• The UUID might appear in public places: user profile pages, comments, forum posts, or shared links.
• The application might have a "report user" or "invite user" feature that reveals the target's UUID in an API request.
• The UUID might be derived from a predictable value (e.g., MD5 of email or username). You can calculate it.

The Course Example: The instructor wanted to access another user's settings but only had a UUID. They found that the "Report User" functionality sent a request containing the target user's UUID. By capturing that request in Burp Suite, they obtained the UUID and then used it to access the target's private data via a different endpoint.

The Lesson: Always look for interactions with other users (report, invite, share, mention). These often leak identifiers that you can reuse elsewhere.

Automating IDOR Discovery with Burp Intruder

When IDs are sequential, you can brute force a range to find valid objects. The course demonstrates this:

1. Capture a request containing a user ID parameter (e.g., GET /api/user?id=358).
2. Send to Intruder (Ctrl+I).
3. Set the payload position on the ID value.
4. Payload type: Numbers. Set a range around your known ID (e.g., from 300 to 400).
5. Run the attack.
6. Sort by response length or status code. A different length may indicate a different user's data (or an error message). A 200 OK with a longer response likely means you found another user's record.

Pro Tip: Start with a small range to avoid flooding the server and triggering rate limiting. Also, respect the program's guidelines on automation.

What Makes an IDOR Report Critical?

Not every IDOR is equal. The severity depends on the sensitivity of the exposed data or the impact of the action.

When reporting: Always demonstrate the impact. Show that you can read sensitive information or perform a destructive action on another account. "I can view user ID 2's email address" is stronger than "I can change the ID parameter."

The Hunter's IDOR Methodology Summary

1. Map the application's object references: Look for IDs in URLs, API paths, request bodies, and even headers. Common parameter names: id, user_id, account_id, order_id, invoice, doc_id, file, uid, guid.
2. Create two accounts. Test all CRUD operations (Create, Read, Update, Delete) between them.
3. Test systematically: For each endpoint that uses an object reference, try:

• Accessing another account's object (read).
• Modifying another account's object (write/update).
• Deleting another account's object (delete).

4. Look for identifier leakage: Use features like "Report User," "Share Profile," or "Invite" to capture UUIDs or other hard-to-guess IDs.

5. Automate when safe: Use Burp Intruder with a reasonable range to discover IDs that aren't obvious.

6. Document clearly: Include the two accounts used, the exact request/response, and the sensitive data or action performed.

Why IDOR Matters: In the OWASP Top 10, Broken Access Control is consistently #1 or #2. IDOR is its most common manifestation. These vulnerabilities are often easy to find once you know where to look, and they pay well because they directly expose user data or allow account takeover. Mastering IDOR will earn you bounties across every type of application — from small startups to Fortune 500 companies.

you can check this article too…

Clap 50 times for this story Leave a comment telling me your thoughts Highlight your Favorite part of the story These tiny actions go a long way, and I really appreciate it.

Thank you for reading and for helping me grow this community!

Medium!