Insecure Direct Object Reference (IDOR)
IDOR occurs when an application exposes direct references to internal objects, allowing attackers to access unauthorized resources by manipulating identifiers.
These payloads are for authorized testing only — systems you own, authorized bug bounty programs, or controlled lab environments. Unauthorized testing is illegal.
What it is
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input without performing access control checks. An attacker can bypass authorization and access resources — user accounts, files, database records — belonging to other users by modifying an ID, filename, or key in a request.
Attack Vectors
- URL parameters containing numeric or sequential IDs
- API endpoints like /api/users/{id} or /api/orders/{id}
- File references with predictable names or paths
- JSON/XML payloads with user or object identifiers
- Cookie or hidden form field values containing IDs
Testing Methodology
- Identify all parameters that reference objects by ID
- Change the ID to another user's ID and observe if access is granted
- Test with sequential IDs (id=1, id=2, id=3)
- Test with another authenticated user's token and your own IDs
- Check for GUIDs or hashed IDs — test predictability
Payloads
Reference payloads for authorized testing. Always verify you have permission before use.
Indicators of Vulnerability
- Response contains another user's data when ID is changed
- Successful action on another user's resource without authorization error
- Different response size or content for valid vs invalid IDs
Detection Guidance
Implement server-side access control checks for every object access. Log object access requests and monitor for ID enumeration patterns.
Mitigation & Remediation
- Implement server-side authorization checks for every resource access
- Use indirect reference maps or UUIDs instead of sequential integers
- Verify that the authenticated user owns or has permission to access the requested resource
- Apply principle of least privilege to all resource access
References
Responsible Use
All content in this reference is for authorized security testing only. Use only on systems you own or have explicit written permission to test.
- Systems and applications you own
- Authorized penetration testing engagements
- Bug bounty programs with defined scope
- Educational lab environments (DVWA, WebGoat, HackTheBox)