This chapter covers Insecure Direct Object References (IDOR) and broader Broken Access Control vulnerabilities, which are among the most critical and frequently tested topics on the PT0-002 exam. Understanding how these flaws arise, how to exploit them, and how to remediate them is essential, as they account for approximately 5-10% of exam questions. You will learn the precise mechanisms behind IDOR, how to detect them during penetration tests, and how to differentiate them from other access control issues. By the end, you will be able to identify, exploit, and report these vulnerabilities with confidence.
Jump to a section
Imagine a large office building where every employee has a personal filing cabinet in a shared storage room. The cabinets are numbered sequentially: 101, 102, 103, and so on. Each cabinet contains sensitive documents like salary records, performance reviews, and medical information. The building's security system is supposed to ensure that employees can only open their own cabinet by requiring a key that matches their employee ID. However, due to a design flaw, the locks are not checked when an employee requests access to a cabinet. Instead, the system simply opens any cabinet whose number is provided in the request. An employee in cubicle 101 can walk to the storage room, pull the handle on cabinet 102, and if the lock is broken (i.e., access control is missing), the drawer opens. The employee can then read or modify the contents of cabinet 102 without ever needing a key for it. This is exactly how Insecure Direct Object References (IDOR) work: the application exposes a direct reference to an internal object (like a file, database record, or cabinet number) and fails to verify that the user is authorized to access that specific object. The attacker simply changes the reference to another object and gains unauthorized access. The underlying mechanism is the absence of an authorization check on each object access, relying solely on the object identifier being hard to guess or expecting the user to only access their own objects.
What is Insecure Direct Object Reference (IDOR)?
Insecure Direct Object Reference (IDOR) is a type of access control vulnerability that occurs when an application exposes a direct reference to an internal implementation object, such as a file, database record, or URL parameter, without proper authorization checks. The vulnerability is not about the reference being exposed—it is about the failure to verify that the user is authorized to access the referenced object. IDOR is classified under the broader category of Broken Access Control, which is ranked #1 in the OWASP Top 10 (2021).
How IDOR Works Internally
To understand IDOR, you must understand how web applications manage user-specific data. Typically, after authentication, the application identifies the user via a session token (e.g., a cookie or JWT). When the user requests a resource, the application uses an object identifier (e.g., a numeric user ID, a file name, or a database primary key) to retrieve the data. In a secure implementation, the application checks whether the authenticated user is authorized to access the object identified by that ID. For example, if user A requests GET /api/orders/123, the application should verify that order 123 belongs to user A. If this check is missing, user A can change the ID to 124 and access user B's order. This is the core of IDOR: the application trusts the user-supplied object reference without verifying ownership or permissions.
Key Components and Defaults
Object Identifier: A parameter used to specify which object to access. Common forms include:
Numeric IDs in URLs: /user/123 - File names: /download?file=report.pdf - Database keys: ?id=456 - API endpoints: GET /api/accounts/789
Authorization Check: The missing component. In a secure app, this check occurs server-side after retrieving the object. Common checks include:
Ownership: Does the object belong to the authenticated user?
Role-based: Does the user's role permit access to this object?
Scope: Is the object within the user's permitted scope?
Default Behavior: Many frameworks do not enforce authorization by default. For example, Ruby on Rails' find method returns a record by ID without checking ownership. Developers must explicitly add authorization logic, often using gems like Pundit or CanCanCan.
Exploitation Techniques
Penetration testers exploit IDOR by manipulating object references. Common techniques include:
Incrementing/Decrementing IDs: Change ?user=100 to ?user=101 and observe the response. This is the most basic test.
UUIDs and Hashes: Even if IDs are not sequential, they may be guessable or leaked elsewhere (e.g., in logs, emails, or client-side code). Testers can attempt to enumerate or brute-force if the ID space is small.
Parameter Pollution: Add extra parameters like ?id=123&id=124 to bypass weak checks.
Path Traversal: Use ../ in file parameters to access files outside the intended directory, e.g., /download?file=../../etc/passwd.
API Enumeration: Access API endpoints that return lists of objects, then modify the object ID in subsequent requests.
Broken Access Control Beyond IDOR
IDOR is a specific form of broken access control, but the exam also tests other types:
Missing Function-Level Access Control: The application does not restrict access to administrative functions. For example, a regular user can access /admin/deleteUser because the server does not check the user's role.
Privilege Escalation: A user with low privileges can perform actions reserved for higher-privileged users, often by manipulating a parameter like role=admin or by accessing a hidden endpoint.
Insecure Direct Object Reference (IDOR): As described above.
Cross-Site Request Forgery (CSRF): Often confused with IDOR, but CSRF tricks a user into performing an action they are authorized for, whereas IDOR exploits missing authorization.
Detection and Testing Methodology
During a penetration test, follow these steps to identify IDOR:
Map the Application: Identify all endpoints that accept object identifiers (IDs, filenames, etc.). Use a proxy like Burp Suite to intercept traffic.
Authenticate as Two Users: Create two accounts (e.g., userA and userB) to test cross-user access.
Capture Requests: For each endpoint, capture a legitimate request from userA and a legitimate request from userB.
Swap Identifiers: Replace userA's object ID with userB's object ID in the request. If the response returns userB's data, an IDOR exists.
Test Different Methods: IDOR may only affect certain HTTP methods (e.g., GET vs POST). Test all methods.
Check for Mass Assignment: In APIs, sending extra parameters like {"id": 123, "role": "admin"} may allow privilege escalation.
Command Examples
Using Burp Suite or curl, you can test IDOR manually:
# Test IDOR on a GET endpoint
curl -X GET "https://example.com/api/orders/123" -H "Cookie: session=userA_token"
# Change to another order ID
curl -X GET "https://example.com/api/orders/124" -H "Cookie: session=userA_token"If the response for order 124 contains data not belonging to userA, the endpoint is vulnerable.
Interaction with Related Technologies
Authentication vs Authorization: IDOR is an authorization failure, not an authentication failure. The user is authenticated but not authorized for the specific object. The exam often tests this distinction.
JWT Tokens: If a JWT contains the user's ID, but the server does not verify that the requested object ID matches the JWT's user ID, IDOR exists. Attackers can modify the JWT or use another user's token.
OAuth: OAuth scopes can limit access, but if the resource server does not enforce scopes per object, IDOR may occur.
Web Application Firewalls (WAF): WAFs can block simple IDOR attempts (e.g., changing numeric IDs), but they cannot prevent logical flaws. The exam may mention that WAFs are ineffective against IDOR.
Remediation
To fix IDOR, implement server-side authorization checks for every object access. Best practices include:
Use Indirect Object References: Instead of exposing database IDs, use random tokens or hashes (e.g., UUIDs) that are hard to guess and not sequential.
Enforce Ownership Checks: Always verify that the authenticated user owns the requested object. For example, in SQL:
SELECT * FROM orders WHERE order_id = ? AND user_id = ?Use Access Control Lists (ACLs): Define permissions per user/role and check them before returning data.
Avoid Exposing IDs in URLs: Use POST requests or include IDs in the request body where they are less visible.
Implement Rate Limiting: To slow down enumeration attempts.
Conduct Regular Code Reviews: Look for missing authorization checks during development.
Map Application Endpoints
Begin by mapping the web application to identify all endpoints that accept object identifiers. Use a proxy tool like Burp Suite to intercept traffic while navigating the application as a normal user. Look for URLs containing parameters such as `id`, `user`, `file`, `order`, `account`, or any numeric or alphanumeric value that appears to reference a resource. Also note API endpoints like `/api/users/123` or `/download?file=report.pdf`. Record each endpoint, the HTTP method (GET, POST, PUT, DELETE), and the parameter name and format. This mapping is critical because IDOR can exist on any endpoint that directly references an object without proper authorization checks.
Create Two User Accounts
Create at least two distinct user accounts with different roles or permissions if possible. For example, create userA (standard user) and userB (standard user) to test horizontal privilege escalation, and optionally an admin user to test vertical privilege escalation. Log in as each user and capture their session tokens (cookies, JWTs, or API keys). Having two accounts allows you to swap object identifiers between users to see if the application enforces object ownership. If the application does not allow self-registration, request test accounts from the client or use any existing accounts you can access.
Capture Legitimate Requests
For each endpoint identified in step 1, capture a legitimate request from userA and a separate legitimate request from userB. For example, userA accesses their own order at `/api/orders/100` and userB accesses their own order at `/api/orders/200`. Use Burp Suite's proxy history or manual interception to capture these requests. Note the exact request parameters, headers (especially cookies or authorization headers), and the response data. This establishes a baseline of what each user can normally access. Make sure to capture both successful responses and any error messages (e.g., 'Order not found' vs 'Forbidden'), as these can reveal information about the authorization logic.
Swap Object Identifiers
The core test: take the session token from userA and modify the request to use an object identifier that belongs to userB. For example, change the URL from `/api/orders/100` to `/api/orders/200` while keeping userA's session cookie. Send the modified request using Burp Repeater or a tool like curl. Observe the response. If the response returns userB's order data (e.g., order details, personal information), then an IDOR vulnerability exists. If the response returns an error like 'Access denied' or 'Not found', the application may have some authorization check. Repeat this swapping in both directions and for all HTTP methods (e.g., POST to create, PUT to update, DELETE to delete). Also test with different parameter types (numeric, UUID, filename) and try manipulating multiple parameters simultaneously.
Enumerate and Exploit Further
If an IDOR is found, attempt to enumerate other objects to determine the scope of the vulnerability. For sequential IDs, try incrementing or decrementing the ID to access adjacent records. For UUIDs, check if they are predictable (e.g., based on timestamps) or if they can be discovered through other means (e.g., in emails, logs, or client-side JavaScript). Also test for mass assignment vulnerabilities by adding extra parameters to API requests (e.g., `{"id": 123, "role": "admin"}`). Document all accessible objects and the data exposed. If the IDOR allows modification (PUT, DELETE), test if you can change or delete other users' data. Finally, attempt vertical privilege escalation by accessing administrative endpoints with a low-privileged user's session, which may reveal additional IDOR or function-level access control issues.
In a real-world penetration test, I encountered a classic IDOR vulnerability in a large e-commerce platform. The application allowed users to view their order history via an API endpoint: GET /api/orders/{orderId}. The orderId was a simple auto-incrementing integer. The application used JWT tokens for authentication, but the server never verified that the authenticated user owned the order. By simply changing the orderId from 1000 to 1001, I could view another customer's order details, including their name, address, phone number, and purchased items. This exposed personally identifiable information (PII) of thousands of users. The remediation was to add a server-side check: before returning the order, the server queried the database with both the orderId and the userId extracted from the JWT. The fix was a single line of code change in the SQL query: SELECT * FROM orders WHERE id = ? AND user_id = ?.
Another common scenario is in healthcare applications. During an assessment of a patient portal, I found that medical records were accessible via GET /records/{recordId}. The IDs were GUIDs, but they were exposed in the URL of the patient's own record. An attacker could potentially brute-force GUIDs if they were generated with a weak algorithm (e.g., using Guid.NewGuid() in .NET, which is cryptographically random but still enumerable if the attacker has a list). More importantly, the application had a 'share' feature that generated a direct link to a record. The link contained the GUID, and the server did not require authentication to access the link. This meant anyone with the link could view the medical record. The fix was to require authentication even for shared links and to limit the link's validity to a short time period.
A third example involves cloud storage services. I tested a file-sharing application where users could upload files and later download them via GET /download?file=filename.pdf. The filenames were stored as provided by the user. By manipulating the filename parameter to include path traversal sequences like ../, I could download arbitrary files from the server, such as configuration files containing database credentials. The root cause was that the application did not sanitize the filename and did not restrict the download directory. The remediation was to use indirect references (e.g., a random token mapped to the actual file path) and to validate that the resolved path is within an allowed directory.
In production environments, IDOR vulnerabilities often go undetected because they require logical testing beyond automated scanners. Automated tools can only detect simple parameter manipulation but miss complex authorization flaws. Penetration testers must manually analyze the application's logic and test every endpoint that handles user-specific data. The impact of IDOR can range from data leakage to full account takeover, depending on the sensitivity of the exposed objects. The CompTIA PenTest+ exam expects you to understand both the exploitation and the remediation of IDOR, as well as how to differentiate it from other access control issues.
The PT0-002 exam tests IDOR and Broken Access Control under Objective 3.2 (Attacks and Exploits) and also under Objective 2.1 (Given a scenario, perform a penetration test). You must be able to identify IDOR in a scenario, explain how to exploit it, and recommend remediation. The exam loves to present a scenario where a user can access another user's data by changing a parameter in the URL. The most common wrong answer is 'Cross-Site Request Forgery (CSRF)' because both involve manipulating requests. However, CSRF requires the victim to be authenticated and the attacker to trick them into clicking a link, whereas IDOR is a direct manipulation of an object reference by the attacker themselves. Another wrong answer is 'SQL Injection' because the attacker is changing an ID parameter, but SQL injection involves injecting SQL code, not just changing a value. The exam will test your ability to distinguish between these.
Key numbers and terms that appear verbatim on the exam: - Insecure Direct Object Reference (IDOR) - Broken Access Control (OWASP Top 10 #1) - Horizontal privilege escalation (accessing same-level user's data) vs Vertical privilege escalation (accessing higher-level functions) - Mass assignment (also called autobinding) - Function-level access control
The exam often describes a scenario with a web application that uses numeric IDs in URLs. The correct answer will be IDOR. They may also present a scenario where an attacker uses a proxy tool like Burp Suite to intercept and modify requests. The question might ask: 'What type of vulnerability is being exploited?' The answer is IDOR.
Edge cases: The exam may test IDOR in RESTful APIs where the object ID is in the path (e.g., /api/users/123) and the server uses the authenticated user's session but does not verify ownership. Another edge case is when the application uses indirect references (like a hash) but the hash is predictable or can be obtained from another source (e.g., in a hidden form field). The exam might also ask about remediation: 'Which of the following is the best defense against IDOR?' The correct answer is 'Implement server-side authorization checks for each object access.' The wrong answers include 'Use HTTPS' (which protects in transit but not logical flaws), 'Use a Web Application Firewall' (which cannot prevent logical flaws), and 'Use input validation' (which prevents injection but not authorization bypass).
To eliminate wrong answers, focus on the mechanism: IDOR is about missing authorization, not missing authentication, not injection, not session fixation. If the scenario describes an attacker changing a parameter to access another user's data, it is IDOR. If it describes an attacker tricking an admin to perform an action, it is CSRF. If it describes injecting SQL into the parameter, it is SQL injection. If it describes manipulating a session token, it is session hijacking or fixation.
IDOR occurs when an application exposes a direct reference to an internal object (e.g., a database key) without verifying the user's authorization to access that specific object.
The exam distinguishes IDOR from broken authentication: IDOR is an authorization flaw, not an authentication flaw.
Common exploitation technique: change the object identifier (e.g., increment numeric IDs) while keeping the session token valid.
Remediation: Implement server-side authorization checks for every object access, typically by verifying ownership or role-based permissions.
Using indirect references (e.g., random tokens) can reduce the risk of enumeration but does not replace authorization checks.
IDOR can affect all HTTP methods (GET, POST, PUT, DELETE) and is not limited to GET requests.
The OWASP Top 10 ranks Broken Access Control as #1, and IDOR is a primary example.
Automated scanners often miss IDOR because it requires logical testing; manual testing is essential.
Horizontal privilege escalation (accessing same-level user's data) and vertical privilege escalation (accessing higher-privilege functions) are both tested.
WAFs cannot prevent IDOR because it is a logical vulnerability, not a signature-based attack.
These come up on the exam all the time. Here's how to tell them apart.
IDOR (Insecure Direct Object Reference)
Involves direct reference to an object (e.g., ID in URL)
Missing authorization check per object
Attacker changes object reference to access other objects
Example: Changing `?user=100` to `?user=101` to see another user's profile
Remediation: Server-side ownership check
Mass Assignment
Involves binding request parameters to object properties automatically
Missing input filtering on object properties
Attacker adds extra parameters to modify object attributes
Example: Adding `&role=admin` to a user update request to escalate privileges
Remediation: Whitelist allowed properties or use Data Transfer Objects (DTOs)
Mistake
IDOR is the same as broken authentication.
Correct
IDOR is a broken access control vulnerability, not broken authentication. The user is properly authenticated (they have a valid session), but the application fails to authorize access to a specific object. Authentication verifies identity; authorization verifies permissions. The exam explicitly tests this distinction.
Mistake
Using GUIDs or UUIDs instead of sequential IDs fully prevents IDOR.
Correct
GUIDs make enumeration harder but do not prevent IDOR. If the server does not verify that the authenticated user owns the object, an attacker who obtains a valid GUID (e.g., from a shared link, email, or client-side code) can access another user's data. IDOR is a logical flaw, not a guessing problem.
Mistake
IDOR only affects GET requests.
Correct
IDOR can affect any HTTP method: GET, POST, PUT, DELETE. For example, an attacker might change the ID in a PUT request to modify another user's data, or in a DELETE request to delete another user's resource. The exam often presents scenarios with POST or PUT to test this.
Mistake
IDOR is the same as mass assignment.
Correct
Mass assignment (also called autobinding) is a separate vulnerability where an attacker modifies object properties by sending unexpected parameters (e.g., adding `role=admin` to a user update request). While both fall under broken access control, IDOR specifically involves direct references to objects. Mass assignment does not require changing the object ID; it manipulates the object's attributes.
Mistake
A Web Application Firewall (WAF) can effectively block IDOR attacks.
Correct
WAFs are ineffective against IDOR because IDOR exploits logical flaws in the application, not signature-based attacks. A WAF cannot determine whether a user is authorized to access a specific order or file. Only server-side authorization checks can prevent IDOR. The exam may present WAF as a distractor.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IDOR is a broken access control vulnerability where the application fails to check if the authenticated user is authorized to access a specific object. Broken authentication refers to flaws in the authentication process itself, such as weak passwords, session fixation, or credential stuffing. In IDOR, the user is properly authenticated but not authorized for the object. The exam tests this distinction: if a user can access another user's data by changing an ID, it's IDOR, not broken authentication.
Yes. UUIDs make guessing harder but do not prevent IDOR. If the server does not verify that the authenticated user owns the object, anyone who obtains a valid UUID (e.g., from a shared link, an email, or client-side JavaScript) can access that object. The vulnerability is the missing authorization check, not the predictability of the ID.
First, map all endpoints that accept object identifiers (IDs, filenames, etc.). Create two user accounts and capture their session tokens. For each endpoint, take the request from userA and replace the object ID with an ID belonging to userB. If the response returns userB's data, the endpoint is vulnerable to IDOR. Also test different HTTP methods and parameter types. Use a proxy like Burp Suite to modify and resend requests efficiently.
The best remediation is to implement server-side authorization checks for every object access. For example, when a user requests an order, the server should query the database using both the order ID and the user ID (from the session) to ensure the order belongs to that user. Additionally, use indirect object references (e.g., random tokens) to avoid exposing internal IDs, but always combine with authorization checks.
No. Path traversal is a specific type of IDOR where the object reference is a file path, and the attacker uses `../` sequences to access files outside the intended directory. However, IDOR is broader: it can involve database records, API resources, or any object reference. Path traversal is a subset of IDOR. The exam may test both separately.
No. A Web Application Firewall (WAF) can detect and block certain attack patterns (e.g., SQL injection, XSS) but cannot prevent IDOR because IDOR exploits logical authorization flaws. The WAF has no way to know whether a user is authorized to access a specific order or file. Only server-side authorization logic can prevent IDOR.
Horizontal privilege escalation occurs when an attacker accesses another user's data at the same privilege level (e.g., user A accesses user B's order). Vertical privilege escalation occurs when an attacker accesses data or functions reserved for higher-privileged users (e.g., a regular user accesses an admin's dashboard). Both can be achieved through IDOR if the object reference is not properly authorized.
You've just covered IDOR and Broken Access Control — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?