Welcome to our final lesson in the "Web Application Security Fundamentals" module. In our previous session, we unpacked Cross-Site Request Forgery (CSRF), an attack that tricks an authenticated user's browser into performing unwanted actions. CSRF exploits the trust a server has in the user's browser. Today, we shift our focus to a different, more direct type of vulnerability: Broken Access Control.
Specifically, we'll investigate Insecure Direct Object References (IDOR), one of the most common and impactful forms of broken access control. Instead of tricking a user, an IDOR attack directly challenges the application's authorization logic, allowing an attacker to access data or functions they should not have permission to see. As a security analyst interested in ethical hacking, mastering the identification of IDORs is a critical skill, as they are a frequent source of high-severity bug bounty findings.
This lesson will describe the mechanics of IDOR vulnerabilities. Upon its completion, we will have covered the foundational web vulnerabilities essential for our practical work, setting the stage for our deep dive into Burp Suite in the next module.
What is Broken Access Control and IDOR?
Broken Access Control is a broad category of vulnerabilities where a user can perform actions or access data outside of their intended permissions. It's so critical that OWASP has listed it as the number one threat in its 2021 Top 10 list. IDOR is a classic and straightforward example of this flaw.
The video below from rs0n_live does an excellent job of distinguishing between IDOR and other access control violations, which is a key concept for a security professional to grasp.
[Part I] Bug Bounty Hunting for IDORs and Access Control Violations
This video provides a clear conceptual framing of IDORs versus other access control issues from a bug bounty hunter's perspective.
Watch the first two segments of the video. The introduction explains why these bugs are so important and difficult to find with automated scanners. Then, pay close attention to the clear example that differentiates an IDOR from a vertical privilege escalation access control flaw.
As explained in the video, an Insecure Direct Object Reference (IDOR) occurs when an application exposes a direct reference to an internal object (like a database record, file, or user account) and fails to verify that the user making the request is actually authorized to access that specific object.
IDOR Hunting with Burp Suite: A $1,000 Bug Bounty | Case Study
This article provides a concise definition and a perfect real-world analogy for understanding IDOR.
Please read the first three sections: What Is an IDOR Vulnerability?, followed by the section on Types of Access Control Issues. The hotel key analogy is particularly effective.
The core issue is a broken access control check. The application correctly verifies that you are an authenticated user, but it doesn't check if you are the owner of the object you are trying to access.
This process is visualized in the diagram below. An attacker identifies a request that uses an ID (1), the request is validated initially (2), but then the attacker manipulates the ID to reference another user's data (3) and sends the request again. Because the server fails to check ownership, it grants access to the sensitive information (4).
The Anatomy of an IDOR Attack
IDORs can manifest wherever an application uses an identifier to fetch or modify data. These identifiers can be found in various parts of an HTTP request:
- URL Path:
GET /api/users/12345/profile - URL Query Parameters:
GET /invoices?invoice_id=9987 - POST Body / JSON Data:
{"userId": "12345", "newEmail": "hacker@evil.com"} - Hidden Form Fields:
<input type="hidden" name="user_id" value="12345"> - Cookies:
Cookie: session=...; user_id=12345
The attacker's process is methodical:
- Use the application normally and identify requests that perform actions on specific objects (e.g., viewing your profile, downloading an invoice).
- Capture this request in a proxy like Burp Suite.
- Locate the direct object reference (the ID).
- Send the request to a tool like Burp Repeater.
- Modify the ID to a different, potentially valid value (e.g., incrementing an integer,
12345->12346). - Resend the request and analyze the response. If you get another user's data, you've found an IDOR.
The image below shows a classic example in Burp Repeater. A request is being sent to modify user 16361157. An attacker could simply change this ID to target a different user.
The following video provides a fantastic, practical demonstration of this process, showing how to hunt for these identifiers in Burp Suite.
Find IDORs Faster — What I Do Every Time 👌
This video by ZACK0X01 is a fast-paced, practical guide to finding IDORs, perfect for your ethical hacking goals.
First, watch the definition of IDOR to solidify the concept. Next, see how a simple IDOR with a numeric ID is found and exploited using Burp Repeater. Finally, watch the section on non-numeric UIDs, which demonstrates a crucial skill: finding leaks of unpredictable IDs elsewhere in the application.
As you saw, the strategy depends on the type of ID. Sequentially numbered IDs are easy to guess and enumerate. For unpredictable IDs like UUIDs, the skill lies in finding other parts of the application that might disclose them.
IDOR in Action: Hands-On Scenarios
To fully appreciate the impact of IDORs, it's best to see them in a practical context. The following article provides several hands-on examples using OWASP Juice Shop and WebGoat, two of the practice applications we will be setting up.
IDOR tutorial hands-on - OWASP Top 10 training
This tutorial walks through several common IDOR scenarios, demonstrating how they can affect data confidentiality, integrity, and availability.
Please read the first three main sections of the article: Affecting Confidentiality: This section shows two examples of reading data you shouldn't have access to, including accessing another user's basket in Juice Shop. Compromising Integrity: Here, you'll see how IDORs can be used to modify data, such as impersonating another user or editing their reviews by first hunting for a "hard to guess" ID. Unauthorized Data Deletion: This final example demonstrates how to escalate the vulnerability by changing the HTTP method (from POST to DELETE) to perform an action that isn't even available in the user interface.
These examples from thehackerish.com highlight the versatility of IDOR attacks. They are not limited to just viewing sensitive information; a successful exploit can allow an attacker to modify or even delete any data the application can access via these identifiers. The final example, where a POST request is changed to a DELETE request, is a key technique in penetration testing: always test other HTTP methods on API endpoints to see if they expose hidden functionality.
Conclusion
In this lesson, we've explored Insecure Direct Object References, the final core vulnerability in our foundational module. You now understand that IDOR is a critical access control flaw where an application fails to verify ownership before acting on an object.
Here are the key takeaways:
- IDOR is a Broken Access Control Flaw: It stems from the server failing to check if the authenticated user is authorized to access the specific object referenced by a user-supplied ID.
- Identifiers are Everywhere: These references can appear in URLs, request bodies, headers, and cookies. Your first task as a tester is to find them.
- Impact Varies: A successful IDOR exploit can lead to unauthorized disclosure of data (confidentiality), modification of data (integrity), or deletion of data (availability).
- Exploitation is Methodical: It involves identifying an identifier, changing its value to target another object, and observing the server's response, often using tools like Burp Repeater.
With this lesson, you have a solid theoretical understanding of the "big four" web vulnerabilities: SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and now IDOR.
We are now ready to get our hands dirty. In our next lesson, we will begin Module 2: Burp Suite Setup and Configuration. We will install the tool, configure our practice lab environments (DVWA and Juice Shop), and ensure our browser traffic is correctly routed through Burp's proxy, preparing us for the practical, hands-on work that will dominate the rest of this course.