IDOR Vulnerability Testing
This skill should be used when the user asks to "test for insecure direct object references," "find IDOR vulnerabilities," "exploit broken access control," "enumerate user IDs or object references," or "bypass authorization to access other users' data." It provides comprehensive guidance for detecting, exploiting, and remediating IDOR vulnerabilities in web applications.
Author
zebbern
Category
Other ToolsInstall
Download and extract to your skills directory
Copy command and send to OpenClaw for auto-install:
IDOR Vulnerability Testing Skills
Overview
The IDOR vulnerability testing skill provides a systematic approach to detect and exploit insecure direct object reference vulnerabilities in web applications. It helps security testers identify access control defects within authorized scopes and offer remediation recommendations.
Use Cases
In security testing engagements with written permission, systematically test the target application for IDOR vulnerabilities to identify horizontal privilege escalation (accessing data between users) and vertical privilege escalation (ordinary users obtaining administrator privileges).
When performing security audits on internal or client web applications, quickly locate risks of object reference enumeration in API endpoints and file download functionalities. Generate vulnerability reports and remediation plans.
Help development teams understand how IDOR vulnerabilities are formed and how to detect them, and learn to correctly implement server-side access control and data ownership validation.
Core Features
Supports detection of database object references (e.g., user IDs, order IDs) and static file references (e.g., invoice PDFs, receipt files), covering various attack vectors such as URL parameters, request bodies, and HTTP method switching.
Provides detailed Burp Suite Intruder configuration instructions, supports Sniper and Battering Ram attack modes, enables bulk enumeration of user ID ranges, and automatically analyzes response status codes to identify vulnerabilities.
Includes secure code examples in frameworks such as Python/Django, demonstrating how to implement proper access control validation, use indirect object references, and filter data ownership on the server side.
Common Questions
What is an IDOR vulnerability?
IDOR (Insecure Direct Object Reference) is an access control vulnerability where an application directly uses identifiers provided by users (e.g., IDs, file names) to access database records or files. An attacker can modify these identifiers to access resources belonging to other users. For example, changing your user ID from 1001 to 1000 may allow you to view another user’s profile.
How do I use Burp Suite to test for IDOR?
First, configure your browser to use Burp Suite as a proxy, log in with a test account, and access a page containing object IDs. After intercepting the request in the Proxy tab, set the ID parameter to the payload position and send it to the Intruder module. Configure numeric-type payloads (range 1–10000). After starting the attack, analyze response status codes—an HTTP 200 status may indicate an IDOR vulnerability.
Why do all my test requests return 403?
If all requests return 403 Forbidden, it indicates the server has implemented basic access control. You can try the following bypass methods: switch HTTP methods (from GET to POST/PUT), add an X-Original-URL header, use parameter pollution (?id=1001&id=1000), test URL encoding variants, or test unauthenticated endpoints and differences between API versions.
Can UUID prevent IDOR?
UUIDs are harder to enumerate than sequential IDs, but they cannot fully prevent IDOR. You can obtain valid UUIDs by analyzing response bodies, JavaScript files, or list API endpoints, or by predicting UUID v1 values using timestamps. Proper protection still requires server-side verification that the requesting user owns the requested resource.
How many test accounts are needed for IDOR testing?
At least two valid accounts are needed: one “attacker” account to send requests, and one “victim” account to confirm whether their data can be accessed. Two accounts can verify horizontal privilege escalation. If you also need to test vertical privilege escalation, you’ll need an additional administrator account to identify the administrator role ID.
How do I fix an IDOR vulnerability that was detected?
The core principle to fix IDOR is that the server must validate that the current user owns the requested resource. Do not query the database directly using an ID provided by the client; instead, filter using the current session user ID. For example, when querying an address, use Address.objects.filter(user=request.user, id=address_id) instead of Address.objects.get(id=address_id).