IDOR: Exploiting Broken Object References

IDOR, or Insecure Direct Object Reference, occurs when an application exposes internal object references — such as database IDs, file paths, or GUIDs — directly in user-controllable input, without enforcing proper access control checks. An attacker manipulates these references to access resources belonging to other users or privileged contexts. The core issue is not the exposure of the reference itself, but the absence of server-side authorization logic that verifies whether the requesting user is entitled to the targeted object. IDOR is classified under OWASP's Broken Access Control category, ranked first in the OWASP Top 10. It affects REST APIs, web applications, mobile backends, and file download endpoints alike. The impact ranges from unauthorized data read to full account takeover, depending on the sensitivity of the exposed object. Sequential integers are the most obvious vector, but UUIDs and hashed identifiers can also be vulnerable if they are predictable or leaked via other endpoints. The vulnerability is particularly dangerous in multi-tenant SaaS environments, where tenant isolation relies entirely on correct access control enforcement at the application layer.

Detecting IDOR attempts from a Blue Team or SOC perspective requires correlation of access patterns rather than analysis of individual requests. A single request to '/api/user/1042' is not inherently suspicious. However, a session iterating through '/api/user/1001' to '/api/user/1999' in rapid succession is a clear enumeration pattern. WAF and SIEM rules should flag high-frequency requests to parameterized endpoints with incrementing or varying object identifiers from a single authenticated session. HTTP 200 responses to requests where the authenticated user ID does not match the requested object ID are a strong indicator — this requires application-layer logging that captures both the session owner and the requested resource identifier. Web application firewalls with behavioral analysis can detect sequential ID probing. At the application level, logging should record the authenticated principal, the requested object owner, and the authorization decision for every sensitive endpoint. Tools like Elastic SIEM or Splunk can correlate these fields. Canary object IDs — fake records inserted into the dataset that should never be legitimately accessed — are an effective honeypot strategy to detect unauthorized enumeration with zero false positives.

During a pentest or Red Team engagement, IDOR testing starts with mapping all endpoints that accept object references as parameters — path segments, query strings, JSON body fields, and HTTP headers such as 'X-User-ID'. Burp Suite's Intruder or the Autorize extension are standard tools for systematic IDOR enumeration. Autorize intercepts requests made as a high-privilege user, replays them using a low-privilege session cookie, and flags responses where access was incorrectly granted. For APIs, tools like ffuf or custom Python scripts with the 'requests' library automate ID range fuzzing. Testers should check not only GET endpoints but also PUT, PATCH, and DELETE operations, where IDOR can lead to unauthorized modification or deletion of records. Indirect IDOR vectors include reference leakage via export features, PDF generation endpoints, or verbose error messages that reveal valid object IDs. Remediation requires enforcing server-side authorization on every object access, using indirect references such as opaque tokens mapped server-side to real identifiers, and implementing a centralized access control layer rather than dispersed per-endpoint checks. Rate limiting on parameterized endpoints reduces enumeration risk but is not a substitute for proper authorization logic.