An Insecure Direct Object Reference (IDOR) occurs when an application uses user-supplied input to directly access objects such as database records, files, or resources without verifying that the requesting user is authorized to access them. By simply changing a reference value like an ID number, filename, or key in a request, an attacker can access data belonging to other users.
How It Works
Consider an application that displays user profiles at /api/users/profile?id=1001. If the server returns the profile for whatever ID is provided without checking that the authenticated user is authorized to view that specific profile, any user can enumerate and view all profiles by incrementing the ID. The same pattern applies to invoices, orders, messages, documents, and any other object accessed by reference.
IDOR vulnerabilities are not limited to sequential numeric IDs. They appear wherever direct references are used: UUIDs in API responses, filenames in download endpoints, email addresses in account lookup functions, and encoded values that can be decoded and manipulated. Using UUIDs instead of sequential integers reduces the guessability but does not fix the underlying problem if authorization checks are still missing.
The vulnerability manifests in various HTTP methods. GET requests might expose data, PUT or PATCH requests might allow modification of other users' records, and DELETE requests might enable destruction of resources belonging to other accounts. Each HTTP method on each endpoint requires its own authorization validation.
Example
A banking application lets users download statements at /api/statements/download?id=5432. The authenticated user's statement ID is 5432, but by changing the parameter to id=5433, they download another customer's bank statement. The server only verified that the user was logged in, not that statement 5433 belonged to them.
Why It Matters
IDOR is one of the most frequently reported and rewarded vulnerability classes in bug bounty programs. It is easy to exploit, often has high impact (exposing personal data, enabling unauthorized actions), and is surprisingly common because developers focus on authentication (is the user logged in?) while overlooking authorization (should this user access this specific resource?). Every endpoint that accepts an object reference must verify ownership or permission on the server side.
Need your application tested? Get in touch.