Hunting IDOR

🔍 What is IDOR?

IDOR (Insecure Direct Object Reference) is a type of access control vulnerability where an attacker can access or modify objects (like user accounts, files, or records) just by changing a reference (e.g., a number in the URL or request body).

🛠️ Step-by-Step Guide to Test for IDOR

🔑 Step 1: Identify Object References

Look for places in the app where:

• URLs contain user/account IDs
• GET /user/12345/profile GET /invoice/12345
• POST/PUT/DELETE requests contain IDs in the body or headers
• { "user_id": 12345 }

👤 Step 2: Create Multiple Accounts

• Register two accounts: your main test account (User A) and a second one (User B).
• Perform actions with both accounts to collect reference values (e.g., user IDs, order numbers).

🧪 Step 3: Replay and Manipulate Requests

Use tools like:

• Burp Suite
• Postman

Steps:

• Log in as User A
• Capture a request like GET /user/12345/profile
• Replace 12345 with User B’s ID (or try guessing it like 12346, 12347)
• Observe the response: can you access another user’s data?

🔄 Step 4: Test All Methods (GET, POST, PUT, DELETE)

IDOR is not just about viewing:

• Can you delete another user’s data?
• Can you edit someone else’s profile?
• Can you download files that belong to others?

📚 Step 5: Enumerate and Brute Force (Carefully!)

• Try sequential ID patterns: 1000, 1001, 1002…
• See if changing the ID gives access to different data.

⚠️ Some programs restrict brute-forcing, so always read the bug bounty policy first.

🔐 Step 6: Check for Authorization Bypass

Even if you’re authenticated, always ask:

“Am I allowed to access this object?”

There should be a server-side check that verifies:

• Who you are
• If you’re allowed to access the resource

If not — that’s an IDOR!

Follow for more