Mastering IDOR: In-Depth Analysis and Exploitation of Insecure Direct Object References

Technical Index:

1. Introduction to IDOR
2. Identifying IDOR Vulnerabilities
3. Effective Note-Taking for IDOR Findings
4. Code Analysis for IDOR Detection
o IDOR in C#/.NET
o IDOR in PHP
o IDOR in JavaScript/Node.js
o IDOR in Python/Flask
5. IDOR Testing Methodologies
6. Automated Testing for IDOR
7. The Art of IDOR Exploitation: Techniques Beyond the Basics
8. Unique and Advanced IDOR Exploitation Techniques
9. Mitigating IDOR Vulnerabilities
10. Case Studies: IDOR Reports from Security Platforms
o Medium Writeups
o HackerOne Reports
11. Practical Demonstrations: IDOR Exploitation Labs
12. Expert Insights: Best Practices from Top Security Researchers
13. Conclusion
Introduction to IDOR

Insecure Direct Object References (IDOR) is a critical web application security vulnerability that
occurs when an application improperly exposes internal object identifiers, such as database keys,
file paths, or user IDs, without implementing proper access controls. This flaw enables attackers
to manipulate these identifiers and gain unauthorized access to sensitive data or perform
unauthorized actions.

IDOR vulnerabilities typically arise due to insufficient validation and authorization checks on
user-supplied input. When an application relies solely on client-side values (such as URL
parameters, form fields, or API requests) without verifying whether the requesting user has the
necessary permissions, it creates an opportunity for malicious exploitation. Attackers can
systematically modify request parameters to access or manipulate data belonging to other users,
potentially leading to severe consequences such as data breaches, account takeovers, or privilege
escalation.

A real-world example of the impact of IDOR was observed in Starbucks' system, where a
vulnerability could have led to the exposure of data from over 6 million customers. The issue
was mitigated before any harm occurred, emphasizing the importance of proactive security
measures. (Read more here)
Visual Representation of IDOR Risk

https://dreamlab.net/en/blog/post/starbucks-idor-how-we-prevented-an-information-leak-of-6-million-
starbucks-customers/

Example from the Image:

 Left Side (No IDOR Vulnerability): A secure web server with good access control
ensures that users can only access their own records. Unauthorized access attempts are
blocked.
 Right Side (IDOR Vulnerability): An insecure web server with bad access control
allows a malicious user to access or modify records belonging to at-risk users, leading
to data exposure or manipulation.

Identifying IDOR Vulnerabilities

Finding an IDOR vulnerability is like sneaking a peek at someone else's diary just by changing a
page number. If a web application isn’t strict about enforcing access controls, attackers can
manipulate a URL or API request to access unauthorized data.

For example, imagine you're on a website with this link:

🔗 example.com/profile?id=123

What happens if you change 123 to 124? If you suddenly see someone else’s profile—boom,
that’s IDOR! This simple parameter manipulation is one of the most common ways IDOR
vulnerabilities are discovered.

Katie Paxton-Fear Methodology-1

Expert Advice on Finding IDORs

A great hacker, Katie Paxton-Fear (widely known as the "API Queen"), provides solid advice
on how to start hunting for IDOR vulnerabilities. She explains techniques that security
researchers and bug bounty hunters can use to efficiently identify these flaws.

▶ Hunting for IDORs with Katie Paxton-Fear

Additionally, you can explore her entire collection of security-focused tutorials on her YouTube
channel:
📺 InsiderPhD YouTube Channel
 Katie Paxton-Fear Methodology-2

Key Points to Watch for in Security Testing

When analyzing web applications for vulnerabilities, focus on the following areas:
 Katie Paxton-Fear Methodology-3

1. IDs or Values That Could Be IDs

 Look for sequential, predictable, or exposed identifiers in URLs, request parameters, and
responses.
 These could indicate potential Insecure Direct Object References (IDORs) when manipulated.

2. APIs Are Full of IDORs

 API endpoints often expose sensitive data or allow unauthorized access if proper validation isn’t
implemented.
 Test API requests by modifying IDs to access other users' data.
3. Complex Permission Hierarchies

 Enterprise applications and multi-user platforms use role-based access control (RBAC).
 Misconfigurations can lead to privilege escalation or unauthorized access to restricted areas.

4. CRUD Functionality (Create, Read, Update, Delete)

 Each action should be tested for authorization flaws.

 Try creating, modifying, or deleting data that belongs to another user.

By carefully examining these areas, security researchers can effectively detect IDOR
vulnerabilities before malicious actors exploit them.

Effective Note-Taking for IDOR Findings (Step-by-Step Guide)

A structured approach to note-taking is essential when identifying and documenting IDOR

vulnerabilities. Bug hunter rs0n_live has shared an effective methodology for keeping organized and
detailed notes while testing for IDOR. You can watch the full video here:
🔗 https://www.youtube.com/watch?v=BfbS8uRjeAg&t=512s

Step 1: Create Two Accounts for Testing

To efficiently test for IDOR, rs0n_live emphasizes the importance of setting up two different
accounts:

 Account A (Victim) – A standard user account with limited access.

 Account B (Attacker) – A separate account used to attempt unauthorized access by
manipulating object references.

rs0n Methodology Part:1

Having two accounts allows you to easily compare requests and analyze access control
weaknesses.
Step 2: Use Visual Studio for Note-Taking

To maintain structured notes, rs0n_live recommends using Visual Studio Code (VS Code). This
tool helps in:

 Keeping logs of all HTTP requests and responses.

 Writing down the request parameters before and after modification.
 Storing payloads and tracking which ones successfully bypass restrictions.

VS Code offers extensions like Markdown Notebooks and REST Client to make note-taking
more efficient.
 rs0n Methodology Part:2

Step 3: Understand the Mechanism of IDOR

The key to effective documentation is to break down the vulnerability mechanism:

1. Identify where user-controlled parameters are being used (e.g., in URL paths, request bodies, or
headers).
2. Check if modifying these values grants unauthorized access.
3. Record every step, including request types (GET/POST), endpoints, and server responses.
rs0n Methodology Part:3
Step 4: Use Xmind for Visualization

For a more structured and visual approach, Xmind is a great tool for creating flowcharts and
mind maps. rs0n_live uses Xmind to:

 Map out request/response flows to understand how IDOR vulnerabilities occur.

 Visualize attack scenarios to explain the impact of an IDOR bug clearly.
 Organize findings in a way that simplifies report writing later.

rs0n Methodology Part:4

🔗 Download Xmind

Step 5: Build Your Own IDOR Methodology

By following this structured note-taking process, bug hunters can refine their own
methodologies. The combination of practical testing, proper documentation, and visual
mapping helps in writing clear and impactful reports.

By adopting this approach, security researchers and bug bounty hunters can effectively analyze
and report IDOR vulnerabilities with precision and clarity.

Here’s your "Code Analysis for IDOR Detection" section structured in a step-by-step manner
with explanations and relevant links.
Code Analysis for IDOR Detection
Understanding how IDOR vulnerabilities manifest in code is essential for both developers and
security researchers. This section provides a step-by-step analysis of vulnerable and secure
implementations across multiple programming languages, including C#/.NET, PHP,
JavaScript/Node.js, and Python/Flask.

Step 1: Identifying IDOR in C#/.NET (ASP.NET MVC)

🔴 Vulnerable Code

⚠️ Issue:

 The application directly retrieves orderId from the request and fetches order details without
verifying ownership.
 Any authenticated user can change the orderId in the query string and view another user's
order.

✅ Secure Code
🔒 Fix:

 Ensures that the UserId associated with the order matches the currently logged-in user.
 Returns 403 Forbidden if an unauthorized user attempts access.

🔗 Further Reading:
.NET Security Best Practices

Step 2: Identifying IDOR in PHP

🔴 Vulnerable Code

⚠️ Issue:

 Directly uses $_GET['user_id'], allowing attackers to modify the user_id in the URL.
 SQL Injection Risk: This code is vulnerable to injection attacks since user input is not sanitized.

✅ Secure Code
🔒 Fix:

 Uses session-based authentication instead of accepting user_id from the query string.
 Uses prepared statements to prevent SQL Injection.

🔗 Further Reading:
PHP Secure Coding Practices

Step 3: Identifying IDOR in JavaScript/Node.js (Express.js)

🔴 Vulnerable Code

⚠️ Issue:

 Retrieves user data based on id in the URL (req.params.id).

 No access control check, allowing unauthorized users to access or modify records by changing
the id.

✅ Secure Code
🔒 Fix:

 Uses session-based authentication (req.session.userId).

 Ensures the requested id matches the authenticated user's session before returning data.

🔗 Further Reading:
Node.js Security Guide

Step 4: Identifying IDOR in Python/Flask

🔴 Vulnerable Code

⚠️ Issue:

 No authentication check before serving user data.

 Attackers can change user_id in the URL to access another user’s information.

✅ Secure Code
🔒 Fix:

 Uses @login_required to restrict access to authenticated users.

 Ensures that user_id matches current_user.id before returning data.

🔗 Further Reading:
Flask Security Best Practices

Step 5: Summary of Security Fixes

Language Issue in Vulnerable Code Fix in Secure Code

C#/.NET No access control check Verify UserId before
returning order data
PHP Uses user_id from query Use session authentication
string, SQL Injection risk and prepared statements
Node.js No session verification for id Check if
in URL req.session.userId
matches requested ID
Python No authentication check for Use @login_required and
user_id in URL compare with
current_user.id

Each secure implementation ensures that users can only access their own data, preventing
unauthorized access, data leakage, and potential IDOR exploits.

IDOR Testing Methodology

The following are various test cases to detect Insecure Direct Object References (IDOR)
vulnerabilities in web applications. These scenarios outline common methods attackers may use
to exploit IDOR and their impact on security.

Checking Below Mindmap we can get a Precise Idea about probable IDOR test cases.
 https://twitter.com/muffymas/status/1408054941445353472?s=20

Here is a refined and organized list of all 33 IDOR (Insecure Direct Object Reference) test cases
with detailed, step-by-step descriptions:

Test Case 1: Don’t Ignore Encoded and Hashed IDs

1. Request: GET /profile?user_id=MTIzNDU=

2. Action: Decode MTIzNDU= (Base64) to reveal 12345.
3. Exploitation: Change the encoded ID to MTIzNDU2 (which decodes to 123456).
4. Impact: Unauthorized access to another user’s profile by manipulating decoded ID.

Test Case 2: Leaking Random or Hashed IDs via Other Endpoints

1. Request 1: GET /api_v1/messages?conversation_id=a9d8f7g6h5j4k3

2. Request 2: GET /api_v1/conversations?user_id=123
3. Response:
4. { "conversation_ids": ["a9d8f7g6h5j4k3", "b3k4l5m6n7o8p9"] }
5. Exploitation: Use a9d8f7g6h5j4k3 to access another user’s messages.
 6. Impact: Exposure of private conversations.

Test Case 3: If You Can’t Guess It, Try Creating It

1. Request: POST /register { "user_id": "user_9876" }

2. Create another account with: POST /register { "user_id": "admin" }
3. Exploitation: If the request is successful, you might create an admin account.
4. Impact: Privilege escalation through ID creation.

Test Case 4: Offering the Application an ID, Even If It Doesn't Ask for One

1. Request: GET /api_v1/messages

2. Modification: Change to GET /api_v1/messages?user_id=456
3. Exploitation: If you see another user’s messages, it’s an IDOR.
4. Impact: Unauthorized access to another user’s private messages.

Test Case 5: HTTP Parameter Pollution (HPP) for IDOR

1. Request Denied: GET /api_v1/messages?user_id=456 returns 403.

2. Exploitation: Modify the request to GET /api_v1/messages?user_id=123&user_id=456.
3. Impact: Access to another user’s data by manipulating parameters.

Test Case 6: Blind IDORs

1. Request: POST /api_v1/export_data { "user_id": 456 }

2. Response: { "message": "Export scheduled" }
3. Follow-up: Receive an email with another user’s data.
4. Impact: Indirect data leak through background processing.

Test Case 7: Changing Request Methods (GET, POST, PUT, DELETE, PATCH)

1. Request: GET /api_v1/messages?user_id=456 returns 403 Forbidden.

2. Exploitation: Change the method to POST /api_v1/messages?user_id=456.
3. Impact: Unauthorized access by bypassing method-based access control.
Test Case 8: Changing File Types

1. Request Denied: GET /api_v1/messages.xml?user_id=456 returns 403 Forbidden.

2. Exploitation: Change to GET /api_v1/messages.json?user_id=456.
3. Impact: Unauthorized access to user’s data by changing file extensions.

Test Case 9: Increasing IDOR Impact with Stored XSS

1. Request: POST
/api_v1/shopping_list?user_id=456&item=<script>alert(1)</script>
2. Exploitation: If the input is stored and executed, you now have XSS via IDOR.
3. Impact: Account takeover through XSS injection.

Test Case 10: Pay Attention to New Features

1. New API: POST /api/CharityEventFeb2025/user/pp/123

2. Exploitation: Change the user ID to 5678 and try: POST
/api/CharityEventFeb2025/user/pp/5678.
3. Impact: Unauthorized actions on new features.

Test Case 11: Add IDs to Requests That Don’t Have Them

1. Original Request: GET /api/MyPictureList HTTP/1.1

2. Exploitation: Modify to GET /api/MyPictureList?user_id=5678.
3. Impact: Unauthorized access to another user’s private pictures.

Test Case 12: Try Replacing Parameter Names

1. Original Request: GET /api/albums?album_id=123

2. Exploitation: Modify to GET /api/albums?account_id=5678.
3. Impact: Unauthorized access to another user’s albums.

Test Case 13: Supply Multiple Values for the Same Parameter

1. Original Request: GET /api/account?id=1234

2. Exploitation: Add another ID: GET /api/account?id=1234&id=1.
 3. Impact: Access admin account details through parameter pollution.

Test Case 14: Try Changing the HTTP Request Method

1. Request: POST /api/account?id=1234

2. Exploitation: Change method to PUT /api/account?id=5678.
3. Impact: Unauthorized update of another user’s profile.

Test Case 15: Try Changing the Request’s Content-Type

1. Request: POST /api/chat/join/123

2. Exploitation: Change Content-type to application/json and send payload { "user":
"admin" }.
3. Impact: Bypass access control through inconsistent content-type checks.

Test Case 16: Change Request Content-Type

1. Request: Content-Type: application/xml

2. Exploitation: Change to Content-Type: application/json.
3. Impact: Potential access control bypass.

Test Case 17: Swap Non-Numeric with Numeric IDs

1. Request: GET /profile?username=user1

2. Exploitation: Change username to numeric ID: GET /profile?username=5678.
3. Impact: Access control issues between non-numeric and numeric IDs.

Test Case 18: Try Using an Array

1. Original Request: {"id": 19}

2. Exploitation: Change to {"id": [19]}.
3. Impact: API fails to validate arrays, leading to unexpected behavior.

Test Case 19: Wildcard ID

 1. Original Request: GET /api/users/1234
2. Exploitation: Change ID to *: GET /api/users/*.
3. Impact: Unauthorized access to all users’ data.

Test Case 20: Change HTTP Method

1. Request: GET /users/delete/VICTIM_ID returns 403 Forbidden.

2. Exploitation: Change method to POST /users/delete/VICTIM_ID.
3. Impact: Delete user data through method change.

Test Case 21: Path Traversal Techniques

1. Request Denied: POST /users/delete/VICTIM_ID returns 403 Forbidden.

2. Exploitation: Modify request path to POST /users/delete/MY_ID/VICTIM_ID.
3. Impact: Path traversal bypass to delete another user’s data.

Test Case 22: Swap Two UUIDs

1. Original Request: GET /v1/orders?cartid=account_2

2. Exploitation: Swap UUIDs to gain access to different data.
3. Impact: UUID-based authentication bypass.

Test Case 23: Send Wildcard Instead of an ID

1. Request: GET /api/users/<user_id>

2. Exploitation: Use wildcard GET /api/users/*.
3. Impact: Unauthorized access to all user data.

Test Case 24: Test Parameter Manipulation

1. Action: Change parameter values to those of other users' IDs.

2. Exploitation: Observe if unauthorized data or functions are exposed.
3. Impact: Data leakage or privilege escalation.
Test Case 25: Test Outdated API Versions

1. Request: GET /v3/users_data/1234 returns 403 Forbidden.

2. Exploitation: Use GET /v1/users_data/1234 to bypass security.
3. Impact: Access to data from outdated API versions with weaker security.

Test Case 26: Test the Same Web Endpoint in Mobile Applications

1. Action: Compare web and mobile API responses.

2. Exploitation: Find discrepancies in security checks between platforms.
3. Impact: Mobile API could allow unauthorized access.

Test Case 27: Never Ignore Encoded/Hashed IDs

1. Action: Create multiple accounts and analyze how hashed IDs are assigned.
2. Exploitation: Manipulate the hash or encoding to access data.
3. Impact: Exposure to unauthorized data based on weak encoding or hashing.

Test Case 28: Google Dorking/Public Forums

1. Action: Search for API endpoints containing user IDs.

2. Exploitation: Find exposed data from misconfigured APIs.
3. Impact: Data leakage through improper security.

Test Case 29: Bruteforce Hidden HTTP Parameters

1. Tools: Use Arjun or Paramminer to uncover hidden parameters.

2. Exploitation: Discover and manipulate hidden parameters for unauthorized access.
3. Impact: Data leakage through brute-forcing hidden HTTP parameters.

Test Case 30: Bypass Object Level Authorization

1. Request: GET /api/v1/messages

2. Exploitation: Add user_id=victim_uuid: GET
/api/v1/messages?user_id=victim_uuid.
3. Impact: Bypass access controls and view unauthorized data.
Test Case 31: Test Parameter Manipulation

1. Action: Review URLs, POST bodies, headers, and cookies for user-referenced object parameters.
2. Exploitation: Manipulate parameters to access other users' data.
3. Impact: Unauthorized access to user data through parameter manipulation.

Test Case 32: Identify User-Controlled Parameters

1. Action: Review RESTful API endpoints for object references.

2. Exploitation: Test with different object IDs in API requests.
3. Impact: Unauthorized data exposure based on weak access controls.

Test Case 33: Test With Different User Roles

1. Action: Test API with accounts having different privilege levels (admin, user, guest).
2. Exploitation: Test if object references can escalate privileges.
3. Impact: Privilege escalation via object manipulation.

Automated Testing for IDOR

Manually testing for Insecure Direct Object References (IDOR) can be time-consuming,
especially when dealing with large applications with multiple roles and permissions. To enhance
efficiency, penetration testers rely on automation tools like PwnFox, Autorize, and
AutoRepeater to identify IDOR vulnerabilities faster and with greater accuracy.

Step 1: Enhancing Session Management with PwnFox

What is PwnFox?

PwnFox is a powerful Firefox extension and Burp Suite plugin developed by @Bitk. It
simplifies web security testing by enabling multiple unique session handling in a single browser
window using Firefox containers.

Key Features:
✅ Firefox Extension – Proxy your browser with Burp Suite and handle up to 8 isolated
container sessions.
✅ Burp Plugin – Highlights requests in different colors based on the container session.

How It Works:

🔹 Open multiple PwnFox tabs in Firefox – each tab is assigned a unique color for clear session
differentiation.
🔹 Requests from each container are highlighted and grouped in Burp Suite’s HTTP history,
making it easier to analyze session-based vulnerabilities.

Using PwnFox for IDOR Testing:

1. Open multiple browser tabs with different user roles (e.g., Admin, Member, Guest).
2. Identify key API endpoints and methods (GET, POST, PUT, DELETE).
3. Modify user IDs, object references, or session tokens in Burp Repeater to check for
unauthorized access.

🔗 Read the full write-up: YesWeHack Blog - PwnFox & Autorize for IDOR
Step 2: Automating IDOR Testing with Autorize

What is Autorize?

Autorize is a Burp Suite extension developed by Barak Tawily that automates the detection of
authorization bypass vulnerabilities, including IDOR.

Installation Steps:

1️⃣ Open Burp Suite → Navigate to Extender > BApp Store.

2️⃣ Search for Autorize and install it.
3️⃣ Find the Autorize tab in Burp Suite.

How to Use Autorize for IDOR Testing:

1. Set Interception Filters to focus on relevant endpoints.

2. Log in as both an attacker and victim (e.g., Admin and Normal User).
3. Copy the attacker's session cookie/token into Autorize.
4. Enable Autorize and interact with the application as the victim.
Detecting IDOR Vulnerabilities:

🔹 Color-Coded Results for Easy Analysis:

 Red ("Bypassed!") → Possible IDOR vulnerability detected.

 Orange ("Is Enforced!") → Some protection exists, but further testing is recommended.
 Green ("Enforced!") → Proper access control is in place.

🔹 Comparing Response Sizes for IDOR Detection:

 Orig. Len – Victim’s response size.

 Modif. Len – Attacker’s replayed request response size.
 Unauth. Len – Response size without authentication.
  If the response length remains unchanged, it’s a strong IDOR indicator!

🔹 Analyze request/response patterns to check if unauthorized access to data is possible.

Step 3: Autorize: Automatic Authorization Bypass Detection

Autorize automatically tests authorization enforcement by sending duplicate requests with

modified session cookies or authorization headers.

🛠️ How It Works:

1. User A (Admin) browses the Web App.

2. Add User B’s cookie in Autorize → It will now browse as User B automatically.
3. Apply Scope Filters to refine results and eliminate noise.
4. Turn ON Autorize and start surfing as User A.
📊 Identifying IDOR:

 If Original Length = Modified Length with 200 OK → ✅ Possible IDOR!

 If 403 Forbidden on Modified Request → ❌ No IDOR!

💡 Tip: Test every Admin function! If a normal user gets 200 OK, it’s an IDOR vulnerability.

🎯 Smart Auditing – Work Less, Hack More!

 Filter Out Non-Vulnerable Requests:

o Check past requests in HTTP History (Proxy Tab).
o Mark non-vulnerable requests out of scope to avoid testing them again.
o Every new request is now unique!

⚡ Playing with AutoRepeater – Advanced Testing

🔗 More details: GitHub - NCCGroup/AutoRepeater

AutoRepeater is a more advanced version of Autorize for precise testing, useful for dynamic
parameters like UUID, SUID, UID.

💡 Key Features:

 Automates replacement of values in requests (e.g., uuid=XYZ123 → uuid=ABC789).

 Can modify requests such as:
o User = Admin
o False = True
o JSON = XML
Setup:

1. Go to Replacement Tab in AutoRepeater.

2. Click Add, enter the Request String and Replace String.
3. Select Replace All, then OK.

🚀 Combine Autorize & AutoRepeater to test not just within a tenant but also across multiple
tenants!

🔗 Watch the tutorial by Stök & Fisher: YouTube - AutoRepeater for IDOR
Step 4: Combining Tools for Maximum Efficiency

🚀 Use PwnFox, Autorize, and AutoRepeater together to streamline IDOR testing and
uncover access control vulnerabilities faster!

🔹 PwnFox – Handles session isolation and simplifies request tracking.

🔹 Autorize – Automates authorization bypass testing for quick IDOR detection.
🔹 AutoRepeater – Automates parameter tampering for deeper privilege escalation testing.

Why Use This Workflow?

✅ Saves time by automating repetitive authorization tests.

✅ Works across web applications, APIs, and multi-tenant environments.
✅ Helps bug bounty hunters & pentesters maximize efficiency while reducing manual
workload.

💡 Tip: Always manually validate automated findings to confirm the vulnerability and report it
with clear proof-of-concept (PoC) evidence!

🔗 Read the full blog: YesWeHack - PwnFox & Autorize for IDOR

Final Thoughts

By leveraging PwnFox, Autorize, and AutoRepeater, security researchers can significantly

speed up IDOR detection and reduce false positives. This approach ensures comprehensive
testing for access control flaws across different user roles, sessions, and object references.

The Art of IDOR Exploitation: Techniques Beyond the Basics

1. Exploiting Create/Update/Delete Operations on Publicly Readable Objects

IDOR vulnerabilities often involve operations such as create, update, or delete, where an object
is readable but should not be writable. A great way to identify such vulnerabilities is by testing
these operations on objects that should be protected.
Pro Tip:
Try modifying objects that are publicly accessible but should not be publicly modifiable. For
example, can you send a PUT request to /api/products to alter the price of a product?
Example on Twitter
2. Discovering Unpredictable IDs Using Archiving and Scanning Tools

Unpredictable IDs may appear to be secure at first, but there are many ways attackers can still
uncover them. Here are several tools and services you can use to find IDs stored in URLs:

 Wayback Machine: Search archived pages for old URLs containing unpredictable IDs.
Wayback Machine Search
 AlienVault OTX: This platform can provide archived URLs that contain IDs in
parameters.
AlienVault OTX API
 URLScan: Scans websites for malicious content and may log unpredictable IDs.
URLScan Search
 Common Crawl: Archives web pages and may capture unpredictable IDs.
Common Crawl
 VirusTotal: Analyzes URLs and can sometimes expose IDs.
VirusTotal API
 Automated Tools: Tools like waymore, waybackurls, and gau can be used to gather
URLs containing IDs.
GitHub - waymore
 Google Search & GitHub Search: Google indexes URLs containing IDs. Similarly,
searching public repositories on GitHub might expose hardcoded IDs.
 Other Techniques:
o Referrer Headers
 o Browser History
o Web Logs
o Insider Threats
o Clickjacking
o Accidental Screen Sharing
o Hard-Coded IDs
o Cryptographic Flaws

3. Exploiting Missing Model IDs

When testing for IDOR in applications with models that reference other models, sometimes
storing non-existent IDs can lead to vulnerabilities.

Link: https://x.com/jobertabma/status/1222194853066358784

Example Scenario: Exploiting IDOR with Missing Model IDs

Target Application: A Bug Tracker

Let's say there is a bug tracker application where users can submit bug reports. Each bug report
is assigned an id, and it references a project_id that the bug belongs to.

Normal Request (Authenticated User)

When a user creates a bug report, the request might look like this:

POST /api/bugs HTTP/1.1

Host: bugtracker.com
Content-Type: application/json
Authorization: Bearer user_token

{
"title": "Crash on login",
 "description": "App crashes when I log in.",
"project_id": 12345 // User's authorized project
}

Attack Strategy

Step 1: Modify the Request in Burp Suite

As an attacker, intercept the request in Burp Suite and modify the project_id to a non-existent
value:

POST /api/bugs HTTP/1.1

Host: bugtracker.com
Content-Type: application/json
Authorization: Bearer attacker_token

{
"title": "Testing bug",
"description": "Checking something...",
"project_id": 99999 // Non-existent project
}

 Here, 99999 is an ID that doesn't exist yet in the database.

Step 2: Observe the Server Response

 If the server does NOT validate the project_id on creation, it might accept and store it,
assuming the project will be created later.
 The response might look like:

{
"success": true,
"bug_id": 56789
}

Even though project_id: 99999 doesn’t exist, the bug report gets created and saved.

Step 3: Exploit Authorization Bypass

 Later, a legitimate user or admin creates the project with ID 99999.

 Since your bug report already references project_id: 99999, you might now be able to
access the project without proper authorization.
Step 4: Access Restricted Data

 If the application checks authorization only when writing but not when reading, you could now
view details of a project you don't own.

Example unauthorized request:

GET /api/projects/99999 HTTP/1.1

Host: bugtracker.com
Authorization: Bearer attacker_token

If the server allows it, you’ve successfully bypassed access control.

4. Path Traversal IDORS

Link: https://x.com/jobertabma/status/1071091295425191937?s=20

Scenario: Microservices-based API with Path Traversal IDOR

Imagine you are testing a banking application that allows users to access their transaction
history using the following endpoint:

GET <https://banking.example.com/api/transactions/123>

Where 123 is your transaction ID.

Potential Vulnerability

The backend microservices architecture may process the request by forwarding it internally to
another microservice using HTTP, such as:

GET /transactions/:id
However, if the application does not properly validate the id parameter and simply extracts the
first integer from the path, it might be vulnerable.

Exploitation using Burp Suite

Step 1: Intercept the Request

1. Open Burp Suite and ensure Intercept is ON in the Proxy tab.

2. Navigate to your transaction history and capture a request like:
3. GET /api/transactions/123 HTTP/1.1
4. Host: banking.example.com
5.

Step 2: Modify the Request

Now, modify the id parameter using a path traversal payload:

GET /api/transactions/123/../456 HTTP/1.1

Host: banking.example.com

This might trick the backend into resolving the path as:

GET /api/transactions/456

If authentication checks only validate the initial ID (123) and ignore the /../456 part, you
could access transaction 456, which belongs to another user.

Step 3: Send the Request & Analyze the Response

1. Forward the request and check the response in Burp Suite's HTTP history.
2. If the response contains another user's transaction details, then the system is vulnerable to
IDOR via path traversal.
Why Does This Happen?

Some microservices architectures use HTTP for inter-service communication. If a backend

service only extracts the first integer from the path, the following may happen:

<?php
$id = (int)$_GET['id']; // Converts "123/../456" to just "123"
echo "Fetching transaction for ID: $id";
?>

Since PHP casts strings to integers and ignores non-numeric characters after the first valid
number, it may validate access based on "123" but then process the path as "456".

5. Creative IDOR Exploits and Testing Strategies

When traditional IDOR testing methods fail, it's important to get creative. Here are a few
strategies to consider:

 Test across APIs: If a web application has corresponding mobile APIs, check them for UUIDs that
may be used for IDOR.
 Guessing Numeric IDs: Use tools like Burp Suite Intruder to brute-force numeric ID ranges (e.g.,
100-1000).
 Try wildcard substitutions: Sometimes using a wildcard (*) in place of an ID works to reveal
unauthorized data.
 Endpoint Testing: If endpoints are named /api/users/myinfo, try /api/admins/myinfo to
check for different access controls.
 Manipulate HTTP Methods: Changing the request method from GET to POST or PUT can
sometimes expose hidden data.
 6. Trick that allowed me to find many IDORs.

7. Credit Section

 @Jhaddix - IDOR Research

 @vickieli7 - Finding More IDORs
 @inonst - BOLA Vulnerabilities
More Insights by @jobertabma on IDOR

These techniques highlight advanced IDOR exploitation methods and provide a foundation for
discovering and testing vulnerabilities in applications. Always remember to use responsible
disclosure practices and report your findings to the appropriate stakeholders.
Unique and Advanced IDOR Exploitation Techniques

IDOR vulnerabilities often extend beyond simple ID replacements. Attackers leverage creative
and advanced methodologies to bypass access controls, exploit insecure implementations, and
chain vulnerabilities for greater impact. Below are some unique techniques used to uncover and
exploit IDOR.

1. No ID, No Worry

Discovery

While testing a web application, an interesting pattern was observed in API requests:

/something/something/self/something

These endpoints returned user-specific information or allowed actions on behalf of the

authenticated user. A key observation was that self acted as a placeholder for the logged-in
user’s ID.

To test for IDOR, the self parameter was replaced with an actual user ID extracted from the
JWT token:

/ngprofile/aggregate/31337/fullProfile
This returned the complete profile details of the authenticated user. When the ID was changed to
another incremented value, the server revealed details of a different user—confirming the IDOR
vulnerability.

Impact

This issue extended to various APIs, including the Change Email API, allowing:

 Modification of any user’s email address.

 Chaining the exploit with the "Forgot Password" function to receive password reset links to an
attacker-controlled email.
 Resetting passwords and taking over accounts.

Key Takeaways

 Always analyze API endpoints for self references.

 Investigate how APIs authorize and validate user identities.

📌 Read more: Starbucks IDOR: How we prevented an information leak of 6 million customers
2. Don’t Just Replace IDs

Scenario 1: Breaking Regex Logic

In an API request:

/accounts/0001176361

Replacing the user ID returned an "Invalid account number" response. However, appending / at
the end:

/accounts/0001176361/

Bypassed the access control restriction and returned sensitive user details.

Scenario 2: Bypassing Authorization with Special Characters

An API endpoint:

api/applications/18385027
Initially, replacing the application ID resulted in a 401 Unauthorized response. However,
adding special characters (%20, %09, %0b, etc.) bypassed the authorization check, exposing full
application details.

Key Takeaways

 Don’t limit IDOR testing to simple ID replacement—fuzz parameters with special characters.
 Regex-based security mechanisms can be bypassed with unconventional inputs.

📌 More details: Finding more IDOR techniques

3. IDOR in GraphQL Applications

Many assume GraphQL APIs are secure, but they can contain IDOR vulnerabilities if
authorization checks aren’t enforced. By revisiting Burp Suite history, GraphQL endpoints were
found in API requests. Replacing object IDs in GraphQL queries revealed unauthorized data.
Key Takeaways

 GraphQL security is often misconfigured, even by large companies like Facebook and Google.
 Always test GraphQL endpoints for IDOR vulnerabilities.

📌 More info: Hunting For Bugs That Scanners Miss by Ayoub Safa

4. Indirect IDOR Exploitation

Step 1: Two accounts were used (attacker and victim), and both had unique
resource IDs.
Step 2: Entering the victim’s resource ID from the attacker account returned 403
Forbidden.

Step 3: Another API endpoint was discovered that accepted the victim’s ID
without proper validation, allowing an update.

Step 4: Returning to the first page (Step 2), the previous restriction was now
bypassed, resulting in 200 OK access.
📌 Real-world example: How I was able to get an account takeover via IDOR from JWT

5. UUID/GUID-Based IDOR Exploitation

Understanding UUID/GUID and Exploitation Techniques

1. What is UUID/GUID?

A UUID (Universally Unique Identifier) or GUID (Globally Unique Identifier) is a 128-bit

number used to uniquely identify objects in computer systems. They are widely used in:

 Databases: To ensure unique identification of records.

 Software Development: For uniquely identifying objects.
 Distributed Systems: To prevent conflicts when multiple systems generate identifiers
independently.

UUIDs are generally represented in hexadecimal format and split into five groups separated by
hyphens:

123e4567-e89b-12d3-a456-426614174000
2. Different Types of UUIDs

UUIDs are categorized into different versions based on how they are generated.

➤ Nil UUID (Version 0)

00000000-0000-0000-0000-000000000000

 A special UUID used for testing, default credentials, or uninitialized values.

 It does not provide any unique identification.

➤ Time-based UUID (Version 1)

e6e3422c-c82d-11ed-8761-3ff799965458

 Generated using the current timestamp and MAC address of the machine.
 The first part encodes the time when the UUID was generated.
 The last section contains a MAC address or random node ID.
 The clock part is usually random but can sometimes be predictable.
➤ Tools for Decoding and Analyzing UUIDs

Several tools help analyze and extract information from UUIDs:

 UUID Decoder: UUIDTools.com

 Guidtool: GitHub - intruder-io/guidtool

3. Real-World Exploitation: Extracting Sensitive Data from UUIDv1

Step 1: Identifying UUID in a Password Reset Link

A web application allows users to reset their passwords by sending a reset link containing a
UUIDv1.
Example:
Step 2: Extracting Timestamp and MAC Address from UUIDv1

UUIDv1 contains a time component, which means an attacker can extract:

1. Exact timestamp when the UUID was generated.

2. System information (MAC address) that created it.

This can be done using tools like Guidtool:

📌 Download here: GitHub - intruder-io/guidtool

3. The Sandwich Attack: Brute-Forcing UUIDv1-Based Reset Links

Sandwich Attack: Brute-Forcing UUIDs

This unique attack method, discovered by security researcher Lupin, demonstrates how
sequentially generated UUIDv1 values can be predicted and brute-forced to enumerate API keys,
reset tokens, or other security-sensitive identifiers. Below is a step-by-step breakdown of the
Sandwich Attack, along with a real-world exploitation scenario.

📌 Original discovery by Lupin: Lupin’s Tweet

📌 Tool for automation: Sandwich Brute-Forcing Tool
📌 Video demonstration: Watch on YouTube
📌 Step 1: Understanding UUIDv1 Structure

Before exploiting the vulnerability, it's essential to understand how UUIDv1 (Universally
Unique Identifier version 1) works. UUIDv1 is composed of the following parts:

 Timestamp (High, Mid, Low) → Records the time when the UUID was generated.
 Clock Sequence → Helps prevent duplicate UUIDs when the system clock is adjusted.
 Node ID (MAC Address) → Stores the MAC address of the machine that generated the UUID.
 UUID Version → Specifies the UUID format (UUIDv1 uses version 1).

🔹 Why is UUIDv1 Predictable?

1. The timestamp is sequential, meaning consecutive UUIDs have timestamps close to each other.
2. The MAC address (Node ID) remains constant if UUIDs are generated on the same machine.
3. The Clock Sequence does not change frequently.

This predictability allows an attacker to reverse engineer UUIDv1 values and predict future or
past UUIDs within a short range.

📌 Step 2: Reverse Engineering UUIDv1 to Extract Timestamps

🔹 Converting UUIDv1 to a Timestamp

UUIDv1 uses a Gregorian Calendar-based timestamp with a fixed offset. To convert it to a
UNIX timestamp:

1️⃣ Extract the Timestamp (High, Mid, Low) from the UUID.

2️⃣ Convert it to a standard epoch timestamp using:

This calculation provides a UNIX timestamp in seconds, revealing the precise moment when the
UUID was generated.
3️⃣ Knowing when a UUID was created helps attackers predict future UUIDs or brute-force
recent ones.

📌 Step 3: Exploiting Batch API Key Generation

Many applications generate multiple API keys or password reset tokens in quick succession
using UUIDv1. This means:

✔ If an attacker obtains one API key, they can estimate the timestamp and machine ID.
✔ Using this knowledge, they can predict and enumerate other users' API keys.

🔹 Real-World Example: API Key Enumeration

1️⃣ A platform assigns UUIDv1-based API keys to users upon registration.

2️⃣ An attacker notices that their API key is:

836d28b2-7592-11e9-8201-bb2f15014a14

3️⃣ By extracting the timestamp, they determine that the API key was generated at 2019-05-13
14:32:10.
4️⃣ Since other users registered at the same time, their API keys have similar timestamps.
5️⃣ The attacker uses brute-force enumeration to predict and test valid API keys.
🔴 Result: The attacker gains access to multiple API keys, leading to a severe security breach.

📌 Step 4: Performing the Sandwich Attack (Real Exploitation Scenario)

The Sandwich Attack can be used to hijack password reset links that rely on UUIDv1.

🔹 Scenario: Predicting Password Reset Links

Consider a web application with a "Forgot Password" feature that generates a UUIDv1-based
reset token and sends it via email.

📌 Example password reset link:

https://www.acme.com/reset/836d28b2-7592-11e9-8201-bb2f15014a14

🔹 Step-by-Step Attack Process

Step 1: Initiate Multiple Password Reset Requests

1️⃣ The attacker requests a password reset for their own email ([email protected]).
2️⃣ Immediately after, they request a password reset for the targeted victim ([email protected]).
3️⃣ Finally, they request a second reset for another attacker-controlled email
([email protected]).

Step 2: Capture and Compare UUID Patterns

The attacker now has two UUIDs from their own password reset requests:

https://www.acme.com/reset/**99874128**-7592-11e9-8201-bb2f15014a14
https://www.acme.com/reset/**998796b4**-7592-11e9-8201-bb2f15014a14

Since UUIDv1 increments sequentially, the victim's password reset UUID must be within this
range.

Step 3: Brute-Force the UUID Range

The attacker systematically brute-forces the hexadecimal range between the two known UUIDs:

99874128 → 998796b4

This space consists of ~22,000 possible UUIDs, which can be brute-forced in under an hour
using tools like:
📌 Sandwich Brute-Force Tool: GitHub - Lupin-Holmes/sandwich
📌 Turbo Intruder (Burp Suite Extension)

Step 4: Identify and Use the Victim’s Password Reset Link

Once the correct UUID is found, the attacker accesses the victim's password reset page:

https://www.acme.com/reset/**99876914**-7592-11e9-8201-bb2f15014a14

They can now change the victim’s password and take over the account.

🚨 Critical Impact: The attacker gains full control over the victim's account without requiring
any credentials.

🔍 Pro Tips & Advanced Exploitation Techniques

While the Sandwich Attack is a powerful method for brute-forcing UUIDv1 values, attackers
can use additional tricks to maximize their success rate. Here are some advanced techniques and
real-world insights that could lead to even bigger security breaches.

🛑 1. Fixed UUIDs for Administrative Users

🔹 In some applications, developers make the critical mistake of assigning fixed UUIDs to high-
privilege accounts, such as administrators or system users.

For example, if you inspect an API response or database dump, you might come across UUIDs
like:

00000000-0000-0000-0000-000000000000
11111111-1111-1111-1111-111111111111
💡 Why is this a problem?

 If these UUIDs correspond to admin users, an attacker could attempt IDOR (Insecure Direct
Object References) to access admin functionalities.
 By modifying their own user ID in requests, they might escalate privileges without
authentication.

🚀 Exploitation Tip:
1️⃣ Look for UUIDs with repeated digits or a pattern like 0000-0000-0000-0000.
2️⃣ Try directly requesting sensitive endpoints using these fixed UUIDs.
3️⃣ If found in API responses, attempt IDOR attacks by replacing your own user ID with the
fixed one.

⏳ 2. Recovering Old UUIDs via Wayback Machine

🔹 Many applications leak UUIDs in public endpoints, forgotten logs, or archived web pages. If
you can recover old UUIDs, you may be able to brute-force the ones that followed.

💡 Why does this work?

 If an app uses UUIDv1, the sequence is predictable because the timestamps increase over time.
 By finding an old UUID, you can calculate the approximate timestamp and guess future values.
🚀 Exploitation Tip:
1️⃣ Use Wayback Machine to search for historical API responses, old password reset links, or
leaked UUIDs.
2️⃣ If you find an old UUID, extract the timestamp and determine the approximate generation
frequency.
3️⃣ Predict the UUID range and use brute force to find the next valid ones.

Example Scenario:

 You find an old password reset link:

 https://www.acme.com/reset/836d28b2-7592-11e9-8201-bb2f15014a14
 The timestamp indicates it was generated yesterday.
 You brute-force nearby UUIDs and discover active reset links still valid today.

🔥 Impact: Full account takeover via password reset link prediction.

🚀 Final Thoughts: Stay One Step Ahead

UUID-based vulnerabilities are often overlooked, but with the right techniques, you can uncover
critical security flaws. Whether it's enumerating admin accounts, predicting password reset
links, or exploiting sequential UUID leaks, mastering these attacks could lead to big bounty
payouts or high-severity CVEs.

📌 Additional Resources and Write-Ups

📌 Video Demonstration: Sandwich Attack on YouTube

📌 Original Tweet from Lupin: View on X (Twitter)
📌 Technical Breakdown of UUIDv1 Security Issues: Versprite Blog
📌 Similar UUID-based Takeover: How I was able to get account takeover via IDOR from
JWT | Mohamed Reda

📌 Final Thoughts

The Sandwich Attack highlights why UUIDv1 should never be used for authentication or
security tokens. Since UUIDv1 is predictable, attackers can enumerate API keys, hijack
password resets, and escalate privileges.

🚀 Pro Tip: If you find UUIDs in an application, check whether they are sequential. You might
uncover a critical vulnerability worth thousands of dollars in bug bounties! 💰

Would you like any additional refinements or explanations? 😊

5. Final Takeaways

✅ UUIDv1 should never be used for security-sensitive tokens (reset links, API keys).
✅ Always check if UUIDs follow predictable patterns in web applications.
✅ Test for sequential UUID vulnerabilities using tools like guidtool and sandwich.
✅ GraphQL and REST APIs using UUIDs can still be vulnerable to IDOR if access
controls are weak.
✅ Regularly audit API security to prevent predictable token generation attacks.
📌 Further Reading:
🔗 Universally Unique Identifiers Attack Methods: Versprite Blog
🔗 Practical UUID Exploitation Guide: Medium Write-Up

Mitigating IDOR Vulnerabilities: A Step-by-Step Approach

IDOR vulnerabilities can be effectively mitigated by implementing proper security controls at

various levels of an application. Below is a structured, step-by-step approach to reducing IDOR
risks:

1. Implement Strong Access Control Mechanisms

 Enforce authorization checks on every request to verify user permissions before granting
access.
 Use server-side validation to prevent unauthorized access.

2. Replace Direct Object References with Secure Identifiers

 Use indirect references like UUIDs or hashed IDs instead of sequential or predictable identifiers
(e.g., user_id=123 → user_id=a1b2c3).
 Avoid exposing raw database keys in URLs or API responses.

3. Adopt Role-Based and Attribute-Based Access Control

 Implement Role-Based Access Control (RBAC) to restrict users based on predefined roles and
permissions.
 Use Attribute-Based Access Control (ABAC) to grant access based on dynamic user attributes,
such as department, location, or device type.

4. Follow the Principle of Least Privilege (PoLP)

 Grant users the minimum access rights necessary to perform their tasks.
 Restrict users from modifying or viewing objects they do not own.

5. Secure API Endpoints

 Validate access before serving any sensitive data.

 Restrict access to APIs using authentication tokens and role-based permissions.

6. Validate and Sanitize User Input

 Prevent ID manipulation by ensuring that users can only access objects they are authorized to.
  Validate user input both client-side and server-side to prevent tampering.

7. Monitor and Log Access Attempts

 Maintain detailed access logs to detect and investigate unauthorized access attempts.
 Use real-time monitoring to identify suspicious activities.

8. Prevent Enumeration and Brute-Force Attacks

 Implement rate limiting and request throttling to prevent automated ID guessing attacks.
 Detect and block excessive failed access attempts.

9. Strengthen Session and Authentication Security

 Bind authentication tokens securely to user sessions.

 Use secure cookie attributes (HttpOnly, Secure, SameSite).
 Implement Multi-Factor Authentication (MFA) for sensitive operations.

10. Conduct Regular Security Audits and Testing

 Perform manual code reviews and automated security scans to identify IDOR vulnerabilities.
 Run penetration tests to simulate real-world attack scenarios.

11. Secure Data Storage and Transmission

 Encrypt sensitive identifiers both at rest and in transit using strong encryption protocols.
 Ensure that API responses return only necessary data (avoid exposing unnecessary user details).

12. Use Centralized Access Control Middleware

 Implement a unified access control layer to enforce security policies consistently.

 Avoid scattered or inconsistent access control checks across different parts of the application.

13. Disable Unused or Deprecated API Endpoints

 Remove old or unnecessary API endpoints to reduce attack surfaces.

 Regularly audit and update API permissions.

14. Secure the Use of JSON Web Tokens (JWTs)

 Validate JWT claims to prevent unauthorized access.

 Use short-lived tokens and refresh them securely.

15. Educate Developers on Secure Coding Practices

 Train developers and security teams on secure access control principles.

  Encourage security-first coding to prevent IDOR vulnerabilities during development.

16. Automate IDOR Detection in CI/CD Pipelines

 Integrate security scanners into development workflows.

 Continuously test for access control flaws during the software development lifecycle (SDLC).

17. Apply Patch Management and Keep Libraries Updated

 Regularly update security libraries and frameworks to fix known vulnerabilities.

 Monitor CVE databases for security patches.

By implementing these measures systematically, organizations can significantly reduce the risk
of IDOR vulnerabilities and enhance the security of their applications.

In-Depth IDOR Case Studies: Real-World Exploits and Lessons from Security Researchers
From Medium"

1. IDOR Found in 5 Minutes

🔗 Read Here

Steps:
1️⃣ Added an alt account to an organization with a "member" role.
2️⃣ Linked a credit card to the admin account.
3️⃣ Captured a POST request to /endpoints/billing/get-account.
4️⃣ Identified parameters: code (organization ID) and id (user ID).
5️⃣ Fuzzed /endpoints/users/org-users and found the admin’s user ID.
6️⃣ Replaced id with the admin’s user ID.
7️⃣ Successfully accessed sensitive billing info (name, address, IP, partial card details).
8️⃣ Reported the vulnerability.
2. Bank Offer IDOR ($5,000 Bounty)

🔗 Read Here

Steps:
1️⃣ Received an email with an offer containing a reservation ID.
2️⃣ Entered the code on the bank’s website and noticed an encoded value in the URL.
3️⃣ Found the decoded version in the response.
4️⃣ Replaced the encoded value with a numeric variation.
5️⃣ Successfully accessed other users’ offers and their personal details.
6️⃣ Stopped testing and reported it immediately.

3. Bank Offer IDOR Fix Bypassed ($10,000 Bounty)

🔗 Read Here

Steps:
1️⃣ Identified that reservation numbers were predictable and sequential.
2️⃣ Noticed that access codes were unique but exploitable.
3️⃣ Used their own access code with another user's reservation number.
4️⃣ Successfully accessed unauthorized offers.
5️⃣ Reported the vulnerability and received a higher bounty.
4. Encryption & IDOR in Insurance Policies

🔗 Read Here

Steps:
1️⃣ API allowed encryption of policy IDs via /api/claims/encrypt?text=POLICY_ID.
2️⃣ Used the encrypted output as an access key.
3️⃣ Accessed /api/certificates/policies/{encrypted_string} to get policy PDFs.
4️⃣ Retrieved full policy details and demonstrated unauthorized access.
5️⃣ Reported the flaw.

5. Found 4 IDORs in One Target

🔗 Read Here

Steps:
1️⃣ Discovered unauthorized account creation by modifying a request.
2️⃣ Found unauthorized invitation deletion by replacing admin cookies with view-only user
cookies.
3️⃣ Tested other CRUD operations and identified additional IDOR vulnerabilities.
4️⃣ Reported them all.

6. Invitation Bypass Exploit

🔗 Read Here

Steps:
1️⃣ Discovered an API for managing company members.
2️⃣ Found a PUT request to /api/roles/<role_id> that assigns roles.
3️⃣ Modified subjects to include a victim’s user ID.
4️⃣ Successfully added the victim without their consent.
5️⃣ Reported the issue.

7. IDOR in Report Export Feature

🔗 Read Here
Steps:
1️⃣ Identified an export feature that generates reports.
2️⃣ Captured a request with a backgroundJobId.
3️⃣ Noticed that the report URL contained this backgroundJobId.
4️⃣ Used Burp Suite’s Intruder to brute-force valid backgroundJobId values.
5️⃣ Successfully accessed other users’ reports.
6️⃣ Reported the vulnerability.

8. Mass Assignment Exploit (ATO)

🔗 Read Here

Steps:
1️⃣ Logged in as a regular user.
2️⃣ Captured a profile update request.
3️⃣ Modified fields like email and roles.
4️⃣ Submitted the request and got a 200 OK response.
5️⃣ Confirmed unauthorized changes and reported it.

9. IDOR + XSS + Account Takeover

🔗 Read Here

Steps:
1️⃣ Discovered an email template edit function.
2️⃣ Intercepted and decoded the request.
3️⃣ Injected an XSS payload <img/src=x onload=confirm(1)>.
4️⃣ Modified eventID to a victim’s ID.
5️⃣ Successfully executed stored XSS.
6️⃣ Verified account takeover potential and reported it.

10. IDOR & Account Takeover (5.17M Users Affected)

🔗 Read Here

Steps:
1️⃣ Found an unauthenticated API exposing consumer details.
2️⃣ Two endpoints allowed attackers to retrieve consumer numbers and sensitive data.
3️⃣ Used brute-force techniques to extract users’ personal information.
4️⃣ Discovered a 0-click account takeover via OTP response manipulation.
5️⃣ Confirmed that mobile numbers were used as session cookies.
6️⃣ Successfully took over accounts without OTP verification.
7️⃣ Reported the severe security flaw.

2. 0-Click Account Takeover via Response Manipulation

 The login flow is flawed, as the mobile number is used as a session cookie.
 Attackers can manipulate the server response after entering a wrong OTP to gain unauthorized
access.
 No OTP verification is required, making account takeover trivial.
 Impact: Full account takeover, exposing critical personal details such as name, email, address,
PAN, voter ID, and Aadhaar number.

Here’s a breakdown of IDOR vulnerabilities from cases 1️1️ to 1️7️, similar to the previous ones:

11. IDOR in HackerOne Embedded Submission Form

🔗 Read Here

Steps:

1️⃣ Captured a GraphQL request using Burp Suite from an embedded submission form.
2️⃣ Identified the uuid parameter in the request.
3️⃣ Modified uuid with a random inactive UUID and still received sensitive program details.
4️⃣ Used Wayback Machine to extract old UUIDs and tested them for access.
5️⃣ Successfully accessed private program names, scope details, and response efficiency rates.
6️⃣ Reported the issue to HackerOne.

12. IDOR Leads to Account Takeover of All Users (ATO)

🔗 Read Here

Steps:

1️⃣ Created two test accounts on the target application.

2️⃣ Discovered sequential user IDs in the /api/v1/user/profile endpoint.
3️⃣ Noticed the auth token was ignored, and only the timestamp mattered.
4️⃣ Generated timestamps in 10-second increments to predict valid ones.
5️⃣ Successfully accessed other user profiles without their consent.
6️⃣ Reported the issue.

13. IDOR in ‘v’ Parameter Exposes All Users’ PII ($1,800 Bounty)

🔗 Read Here

Steps:

1️⃣ Found a 64-character v parameter that included predictable sections.

2️⃣ Modified characters outside curly braces to test different values.
3️⃣ Successfully accessed other users' personal data by changing just a few characters.
4️⃣ Used automation scripts to test multiple variations.
5️⃣ Reported the flaw.

Example of the Vulnerability

Original ‘v’ parameter:

vnnt {xrjo} nnnr {tgx} ntkx {tgyj} yinvr {mrzo} jyg {tnkxn} ugor {qnjn} zyjr
{irgirnittghn}

By modifying characters outside the curly braces, different users’ data can be accessed:

Example modified values:

1. vnnt {xrjo} mqrn {tgx} ntkx {tgyj} yinvr {mrzo} jyg {tnkxn} ugor {qnjn}
zyjr {irgirnittghn}
2. qrnt {xrjo} nnnr {tgx} ntkx {tgyj} yinvr {mrzo} jyg {tnkxn} ugor {qnjn}
zyjr {irgirnittghn}

14. IDOR in Image Upload Function

🔗 Read Here

Steps:

1️⃣ Found an image upload feature where each user had a profile ID.
2️⃣ Noticed that modifying /profile/1000 to /profile/1002 returned another user’s images.
3️⃣ Uploaded an image as User A, then accessed User B’s profile using a simple IDOR.
4️⃣ Confirmed the ability to overwrite other users’ profile pictures.
5️⃣ Reported the vulnerability.

15. Privilege Escalation via IDOR ($9,000 Bounty)

🔗 Read Here

Steps:

1️⃣ The owner of a project could create private folders, files, and review links.
2️⃣ A search function was available for both owners and collaborators.
3️⃣ Removed the search query from the request (q parameter).
4️⃣ Received a leak of all owner metadata and invite links.
5️⃣ Used the invite links to gain unauthorized access to private data.
6️⃣ Reported the issue and secured a high bounty.

16. Second-Order IDOR in Banking App

🔗 Read Here
Example 1: IDOR in Transaction Receipt Retrieval

1️⃣ Requested a valid transaction receipt (show_receipt.aspx?id=XXXXXX).

2️⃣ Modified the ID to another user’s receipt but got a receipt_error.aspx response.
3️⃣ Paused redirection, changed the ID, and then resumed the original request.
4️⃣ Successfully retrieved another user’s transaction receipt.

Example 2: Second-Order IDOR via Audit Logs

1️⃣ Private messages were protected (showMessageBody endpoint).

2️⃣ However, the audit logs stored user activity without proper access control.
3️⃣ Retrieved restricted message details by accessing the logs instead of the main endpoint.
4️⃣ Reported the issue.

17. IDOR in Account Management System (Admin Privilege Escalation)

Steps:

1️⃣ Admin could add new users via an API request containing:

 CSRF Token
 Request ID (RQ-ID)
 Auth Token
2️⃣ Removing RQ-ID and CSRF Token caused a 403 Forbidden error.
3️⃣ Removing only the Auth Token allowed the request to proceed successfully.
4️⃣ Extracted a victim’s account ID and used it in the request.
5️⃣ Bypassed authentication, granting admin access to another user’s account.
6️⃣ Reported the security flaw.

Case Study: IDOR Reports on HackerOne

Many believe that IDOR (Insecure Direct Object Reference) is simply about changing an "ID"
parameter in a request and swapping it with another user’s ID to access unauthorized data. A
prime example of this is Report 797685. However, IDOR extends beyond account-based access
control and numeric ID parameters—it can appear in various formats and locations, as
explored below.
 https://hackerone.com/reports/797685

Where Are IDORs Commonly Found?

Based on an analysis of various HackerOne reports, IDOR vulnerabilities are frequently found
in:

Graph showing where IDORs are commonly found

📌 REST APIs (GET/POST request bodies) 📌 GraphQL APIs 📌 URL parameters 📌

Hidden fields in forms 📌 JavaScript source code 📌 Direct file/resource access links
"IDOR is a Low-Hanging Fruit That Takes No Skill" – A Misconception

While some believe that IDOR is an easy vulnerability to find, it actually requires creativity
and skill to identify effectively. In fact, IDOR often leads to higher bug bounties than Privilege
Escalation (Privesc), SQL Injection (SQLi), or Code Injection due to its impact.

Key Techniques to Improve Your IDOR Hunting

1. Finding Non-Incremental IDs

Not all IDs are sequential. Sometimes, IDs must be extracted from different sources. ✅
Example: Extracting an ID from an asset link (Report 404797).

https://hackerone.com/reports/404797

2. Extracting IDs from Page Source

IDs can sometimes be hidden in: 🔹 JavaScript source code 🔹 Hidden input fields 🔹 API
responses ✅ Example: Finding IDs in a Twitter-like platform’s source code (Report 181748).

https://hackerone.com/reports/181748

3. Checking for Encoded or Plaintext IDs

🔹 Are IDs visible as plaintext or encoded (e.g., Base64)? ✅ Example: Report 291721.
4. Direct File/Resource Access Without Authentication

If files or documents are accessible via direct URLs, they may be vulnerable. ✅ Examples:

 Report 94790
 Report 258260 (IDOR on an image)
 Report 230328

https://hackerone.com/reports/258260

5. Finding IDORs in Less-Protected Similar Sites

A vulnerability patched on the main site may still exist on: 🔹 Regional versions 🔹 Different
API endpoints ✅ Examples:

 Report 876300
 Report 715054
 Report 271393

6. Exploiting IDOR via Different HTTP Methods

🔹 Changing request methods (GET → POST, POST → PUT) can reveal IDOR vulnerabilities.
✅ Examples:
  Report 199321
 Report 204984
 Report 297751

7. Using Non-Numeric Identifiers

IDOR doesn’t always involve numbers—sometimes, emails or usernames are vulnerable. ✅

Examples:

 Report 152407
 Report 262661
 Report 587687

https://hackerone.com/reports/152407

The Impact of IDOR

IDOR vulnerabilities can have serious consequences beyond just account takeovers (P1 bugs).
Other significant impacts include:

1. Leaking Personally Identifiable Information (PII)

🛑 Some IDORs expose sensitive user data, such as email addresses. ✅ Example: Report
293490 (Leaks user emails).
 https://hackerone.com/reports/293490

2. Bypassing Payment Mechanisms

💰 IDOR can allow attackers to bypass payment verification. ✅ Example: Report 391092.

https://hackerone.com/reports/391092

3. Performing Actions on Behalf of Other Users

🔹 Attackers can initiate actions as another user without consent. ✅ Example: Report
1005020.

4. Destroying or Manipulating Assets

⚠️ IDOR can enable attackers to delete or modify critical assets. ✅ Examples:

 Report 156537
 Report 264754
 Report 153905

Summary / Key Takeaways

✅ IDOR vulnerabilities extend beyond simple ID parameter tampering. ✅ 80% of IDORs are
found in REST APIs, GET parameters, or POST bodies. ✅ Creativity is key—try encoding
tricks, alternate domains, and HTTP method changes. ✅ IDOR impact is vast, including
PII leaks, payment bypasses, and asset manipulation.

🔎 By thinking outside the box and testing different scenarios, you can significantly increase
your chances of discovering valuable IDOR vulnerabilities.
📌 For a full in-depth write-up, check out this amazing article: 🔗 What I Learned from
Reading 220 IDOR Bug Reports

👏 Special thanks to @BrownBearSec for this insightful analysis!

11.Practical Demonstration: IDOR Exploitation on PortSwigger

Labs
Here’s a step-by-step breakdown of solving the IDOR lab:

Step 1: Understanding the Lab Setup

 The lab stores user chat logs on the server's file system.
 These chat logs are retrieved using static URLs.
 The goal is to find the password of the user "carlos" and log into their account.

Step 2: Identifying Potential Entry Points

 The interface provides multiple clickable areas:

1. View Details (to check items)
2. Top-right menu (Home, Account Login, Live Chat)
3. Live Chat (mentions chat logs in the description)
 Since the lab description specifically mentions stored chat logs, Live Chat is the most
relevant entry point.
Step 3: Observing Chat Behavior

 The chat interface shows interactions with a bot named "Hal."

 Any message sent receives a response from Hal.
 Clicking the "View transcript" button downloads a chat log of the conversation.

Step 4: Analyzing the Transcript Download Request

 When clicking View transcript, a GET request is sent to retrieve a chat log.
 The request is structured like this:
  GET /download-transcript/2.txt HTTP/1.1
 Host: vulnerable-website.com
 The chat log file name increments with each request (e.g., 2.txt, 3.txt, etc.).

Step 5: Testing for IDOR

 Since the parameter directly references a file and increments, there’s a chance that earlier
logs (like 1.txt) belong to another user.
 Using Burp Suite, intercept the request and modify the parameter:

Original request:

GET /download-transcript/2.txt HTTP/1.1

Modified request:

GET /download-transcript/1.txt HTTP/1.1

 If the server lacks proper Access Control, it will return another user’s chat log.

Step 6: Extracting Carlos’ Password

 If the altered request succeeds, it retrieves the chat log from another user (Carlos).
 The chat log contains Carlos' password.

Step 7: Logging into Carlos’ Account

 Successfully logging in completes the lab.

Important Takeaways

 IDOR (Insecure Direct Object Reference) occurs when access to a resource (file, record, or
function) is determined solely by a user-controllable parameter.
 The vulnerability in this case was that the server did not verify if the requesting user was
authorized to access certain chat logs.
 Similar vulnerabilities can exist in different scenarios:
o Invoices: http://example.com/somepage?invoice=001
o Password changes: http://example.com/changepassword?user=abg
o File downloads: http://example.com/downloadFile?fileName=1.txt
o Accessing restricted pages: http://example.com/accessPage?item=i-14

For more understanding you can also read the below writeup:

https://medium.com/@aysebilgegunduz/everything-you-need-to-know-about-
idor-insecure-direct-object-references-375f83e03a87
Case Study: IDOR Reports on HackerOne
Here’s the refined version with the Insider PhD video link included:

📌 GitHub Repositories

Explore different vulnerability types and analyze complete reports. Feel free to skip reports that
seem too easy.

 HackerOne Reports
 Awesome Bugbounty Writeups
 Awesome Google VRP Writeups
 HackerOneReports

💰 High Bounty Awards Reports on IDOR

A collection of high bounty reports related to Insecure Direct Object Reference (IDOR).

 Bug Bounty Reports Explained - IDOR Case 1

 Bug Bounty Reports Explained - IDOR Case 2
 Bug Bounty Reports Explained - IDOR Case 3

🔍 Enumerating IDORs in All Possible Ways

Master IDOR enumeration techniques through these in-depth videos.

 Enumerating IDORs - Video 1

 Enumerating IDORs - Video 2
 Enumerating IDORs - Video 3

🎥 Additional Learning

 Insider PhD - Hunting IDORs & Authentication Issues

Conclusion

Insecure Direct Object References (IDOR) remain one of the most critical security
vulnerabilities, often leading to severe data breaches if left unaddressed. Throughout this deep
dive, we have explored various aspects of IDOR, from identification and exploitation techniques
to mitigation strategies and real-world case studies. By leveraging manual testing, automated
tools, and expert insights, security professionals can effectively detect and remediate these
vulnerabilities. As organizations continue to strengthen their security posture, prioritizing IDOR
prevention through secure coding practices, rigorous access controls, and continuous monitoring
is essential. Understanding and addressing IDOR not only enhances application security but also
safeguards user data and organizational integrity in an increasingly threat-prone digital
landscape.