| name | idor-detection |
| description | Detect Insecure Direct Object Reference vulnerabilities in APIs and web applications |
| domain | web-security |
| subdomain | idor |
| tags | ["web","idor","authorization","access-control"] |
| version | 1.0.0 |
| author | BerkahKarya |
| license | MIT |
IDOR Detection
When to use
Apply this skill when testing applications with user-specific resources accessed via identifiers (user IDs, document IDs, order IDs) in URLs or API endpoints.
Detection steps
- Map object references: Identify endpoints that include object identifiers (e.g.,
/api/users/123, /documents/456, /orders/789).
- Create two test accounts: Register two accounts (Account A and Account B) to test cross-user access.
- Capture requests from Account A: Note the object IDs that Account A can legitimately access.
- Attempt access from Account B: Using Account B's session, try to access Account A's objects by substituting the identifier.
- Check all HTTP methods: Test GET (read), PUT/PATCH (modify), DELETE (remove) — not just read access.
- Test incremental IDs: If IDs are sequential, try incrementing/decrementing (e.g.,
/api/users/124 after /api/users/123).
Common patterns
/api/v1/users/{id}/profile — user profile access/api/v1/documents/{id}/download — document access/api/v1/orders/{id} — order details/api/v1/admin/users/{id}/settings — admin functions
False positive indicators
- The endpoint returns generic data not specific to the ID (e.g., a shared template)
- The application enforces object-level authorization and returns 403
- The ID is a UUID and the application validates ownership server-side
Reporting
Demonstrate the IDOR by showing Account B successfully accessing Account A's private data, with both the request (including Account B's session) and the response (showing Account A's data).
