IDOR Vulnerability Writeup: Exploiting Insecure Direct Object References

Insecure Direct Object Reference (IDOR) is a critical access control vulnerability that occurs when an application uses user-supplied input to access objects directly without performing an adequate authorization check. This flaw allows attackers to bypass authorization and access sensitive data, such as private user profiles, financial records, or system configuration files, by simply modifying a parameter value in a request.

TL;DR:

• IDOR occurs when authorization logic is missing or flawed at the object level.
• Common targets include database keys (ID=101), filenames, and UUIDs in API endpoints.
• Bypass techniques involve HTTP Parameter Pollution (HPP), method swapping, and JSON wrapping.
• Prevention requires strict Role-Based Access Control (RBAC) and the use of indirect object references.

Understanding the Mechanics of IDOR Vulnerabilities

At its core, an IDOR vulnerability is a failure of the application’s authorization layer. While authentication verifies who a user is, authorization determines what that user is allowed to do. In an IDOR scenario, the application correctly identifies the user but fails to verify if that user owns or has permission to view the specific resource they are requesting. This often happens because developers assume that users will only interact with the identifiers presented in the UI, forgetting that any client-side data can be manipulated using tools like Burp Suite.

There are two primary types of IDOR: Horizontal Privilege Escalation and Vertical Privilege Escalation. Horizontal escalation involves accessing resources belonging to another user with the same permission level. For example, User A accesses the private messages of User B. Vertical escalation occurs when a low-privileged user accesses resources meant for a higher-privileged user, such as an administrator. Both represent a massive breakdown in the security posture of an application.

Statistically, IDOR vulnerabilities consistently rank among the most common and highest-paying bugs in bug bounty programs. In 2023, reports on platforms like HackerOne showed that access control vulnerabilities, including IDOR and Broken Object Level Authorization (BOLA), accounted for over 15% of all critical findings. The simplicity of exploitation combined with the high impact on data privacy makes this a priority for any web application security testing guide.

Key Takeaway: Never trust client-side input for authorization decisions. Every request for a resource must be validated against the user's current session permissions on the server side.

Identifying Attack Surfaces for IDOR Vulnerabilities

Finding IDOR requires a keen eye for where an application references internal objects. You should look for parameters in the URL, headers, or body that look like identifiers. These are often labeled as `id`, `user_id`, `account_number`, `order_ref`, or `file_name`. When you see a numeric value like `?user_id=5432`, the immediate test is to increment or decrement that value to see if the application returns data belonging to another user.

Modern applications frequently use RESTful APIs, where identifiers are part of the URL path itself. An endpoint like `/api/v1/users/99/profile` is a prime candidate. To effectively map these, you should follow a structured API pentesting methodology. This involves intercepting all traffic and documenting every endpoint that accepts an ID. Even if the ID is a Universally Unique Identifier (UUID), do not assume it is secure; UUIDs can sometimes be leaked in other API responses or predicted if they are version 1 (time-based).

Beyond the obvious GET requests, check POST, PUT, and DELETE methods. Often, developers secure the "view" action but forget to secure the "edit" or "delete" actions. Changing your own profile might trigger a `PUT /api/profile/update?id=1001`. Changing that ID to `1002` could allow you to modify another user's account details. This is why IDOR is a critical component of any pentest checklist.

Advanced Bypass Techniques for Modern IDORs

As developers become more aware of basic IDOR, they implement simple checks that can often be bypassed with more sophisticated techniques. One common defense is checking the `Referer` header or using a custom token. However, if the core authorization logic is still missing, these "security through obscurity" measures won't hold up. For instance, if a target uses a security headers check to ensure certain protections are in place, it might still be vulnerable to logic flaws at the application level.

HTTP Parameter Pollution (HPP)

HPP involves supplying multiple parameters with the same name. Some web servers and frameworks process only the first occurrence, while others process the last. If the authorization check looks at the first `id` but the database query uses the last one, you can bypass the check. Example: `GET /api/view?id=YOUR_ID&id=VICTIM_ID`. The application might authorize you for `YOUR_ID` but return data for `VICTIM_ID`.

Method Swapping and Content-Type Manipulation

If a `GET` request is protected, try changing it to a `POST` or `PUT` request with the same parameters. Conversely, if a JSON-based API endpoint is secure, try sending the data as `application/x-www-form-urlencoded` or `application/xml`. Sometimes, the authorization logic is only applied to the expected Content-Type. This is why testing various input formats is essential during a web application security testing guide execution.

Wrapping IDs in Arrays or Objects

If the backend uses a framework that automatically parses JSON, try changing a simple ID value into an array. Instead of `{"user_id": 123}`, try `{"user_id": [123, 124]}` or `{"user_id": {"id": 124}}`. This can sometimes confuse the authorization logic while the database driver still extracts the target ID correctly. This technique is particularly effective in Node.js and Ruby on Rails environments where type juggling is common.

Key Takeaway: Bypassing IDOR defenses often requires changing the way the server perceives the input. Always test how the backend handles unexpected data types or duplicate parameters.

Automating IDOR Discovery: Tools and Extensions

Manually testing every ID in a large application is tedious and prone to error. Professional bug bounty hunters use automation to flag potential IDORs. The most effective tool for this is Burp Suite. By using the Burp Suite tutorial for pentesters, you can master extensions like Autorize.

Autorize works by repeating your requests with a different session cookie. You browse the site as User A (high privileged or owner), and Autorize automatically replays those requests using the cookie of User B (low privileged or different user). If the response from the replayed request matches the original response in length and content, you likely have an IDOR. This tool saves hours of manual labor and ensures you don't miss hidden endpoints.

Another useful tool is AutoRepeater, which allows you to define replacement rules for every request. For example, you can set a rule to replace your `user_id` with a victim's `user_id` globally. This is helpful when IDs are buried in headers or complex JSON structures. When performing network-wide assessments, using an online port scanner can help identify internal API services that might not be exposed through the main web interface but are reachable via SSRF or other vectors.

Custom scripting in Python is also a powerful way to find IDORs. You can write scripts to iterate through a range of IDs and check for changes in response length or HTTP status codes. This is particularly useful for unauthenticated IDORs where you are trying to access resources like invoices or receipts that should be private but are exposed to the public internet.

Real-World IDOR Writeup: Exploiting a Multi-Tenant SaaS

To illustrate the impact, let's look at a practical scenario involving a SaaS platform for managing company invoices. The platform uses a structure where each company has its own workspace. A user from Company A should not see invoices from Company B.

During the assessment, I identified an endpoint: `GET /api/v2/workspaces/881/invoices/export?format=pdf`. Here, `881` is the `workspace_id`. By simply changing the `workspace_id` to `882`, the server returned a PDF containing the financial data of a completely different company. The application was checking if I was logged in, but it was not checking if my user account was associated with `workspace_id` 882.

The exploitation steps were:

1. Login as a low-privileged user in Company A.
2. Capture the invoice export request in Burp Suite.
3. Send the request to Repeater.
4. Change the `workspace_id` to a known ID of Company B (found via public directories or simple enumeration).
5. Analyze the response. If the PDF downloads, the IDOR is confirmed.

The severity of this finding was "Critical" because it allowed for mass data exfiltration. An attacker could script this to download every invoice in the system by iterating through the `workspace_id` range from 1 to 10,000. This highlights why authorization must be enforced at every single object access point, not just at the login page.

Remediation Strategies: Moving Beyond Obscurity

Fixing IDOR requires a systematic approach to authorization. The most effective method is to implement Indirect Object References. Instead of exposing the database primary key (e.g., `id=505`), the application should use a temporary, session-specific mapping. For example, a user sees `file_id=1`, which the server maps internally to database ID `505` only for that specific user session. When the session ends, the mapping is destroyed.

If direct references must be used, such as UUIDs, the application must implement a strict authorization check. Before fetching the object from the database, the code should perform a check similar to: `SELECT * FROM invoices WHERE id = ? AND company_id = ?`. By including the `company_id` (retrieved from the user's secure session) in the query, the database itself enforces the authorization, ensuring that a user can only ever retrieve their own data.

Furthermore, use a centralized authorization module or middleware. This reduces the risk of a developer forgetting to add an authorization check to a new endpoint. Modern frameworks like Django or Laravel offer built-in policies and gates that make this much easier to manage. Regularly auditing your code and performing penetration tests is the only way to ensure these controls remain effective as the application evolves.

Frequently Asked Questions

What is the difference between IDOR and BOLA?

IDOR (Insecure Direct Object Reference) and BOLA (Broken Object Level Authorization) are essentially the same thing. IDOR is the traditional term used in the OWASP Top 10, while BOLA is the term specifically used in the OWASP API Security Top 10. Both describe the same failure to check permissions when accessing a specific object via an identifier.

Can UUIDs prevent IDOR attacks?

No, UUIDs do not prevent IDOR; they only make the identifiers harder to guess. This is known as "security through obscurity." If a UUID is leaked in an API response, a URL, or a JavaScript file, an attacker can still use it to perform an IDOR attack. Proper authorization checks are the only real defense.

How do I test for IDOR if I only have one account?

Testing for IDOR with one account is difficult but possible. You can look for "Unauthenticated IDOR," where you try to access resources without being logged in at all. However, to find "Horizontal IDOR," you generally need two accounts (User A and User B) to see if User A can access User B's private data. If you only have one account, you can try to guess or find other IDs through public-facing parts of the site.

Is IDOR always a high-severity vulnerability?

Usually, yes. Because IDOR often leads to unauthorized data access or modification, it is typically rated as High or Critical. The severity depends on the sensitivity of the data exposed. An IDOR that leaks public profile information might be Medium, while one that leaks credit card details or allows password resets is always Critical.

Mastering the IDOR vulnerability writeup process is a fundamental skill for any security professional. By understanding the underlying logic failures and using the right tools to automate discovery, you can identify these high-impact flaws before attackers do. Always remember that security is a continuous process, and a single missed authorization check can lead to a massive data breach.