IDOR (Insecure Direct Object Reference)
IDOR exposes objects by id without checking that the requester has permission to access them.
Definition
Insecure Direct Object Reference (IDOR) is the class of broken-access-control bugs in which an application exposes a resource by a predictable identifier (a numeric id, a UUID embedded in a URL) and authorises access based on "the request reached this handler" rather than "this principal is allowed to see this resource". Incrementing the id reveals another user's record.
IDOR is the single most under-reported bug in pentests because it requires a real "what is the policy" conversation. There is no library that fixes IDOR — every endpoint has to enforce its own authorisation. As a result, the bug is endemic; almost every large application has at least one.
How it works
The application exposes `GET /api/invoices/{id}`. The handler looks up the invoice by id and returns it, assuming that whoever sent the request through the auth gateway is authorised to see any invoice. The attacker — a legitimately-authenticated user — substitutes another user's invoice id and reads it.
Impact
Data leakage at scale (any authenticated user can read every record), tenant escape on multi-tenant systems, account takeover when the leaked field is a password-reset token or a verification code.
Mitigation
Authorise every record access at the model layer: every query that loads a record must include a `WHERE owner_id = current_user_id` clause, or an explicit policy check immediately after the load. Prefer scoped repositories over global repositories. Use unguessable identifiers (UUIDv4) where appropriate, but treat that as defence-in-depth, not the primary control. The OWASP API Security Top 10 lists IDOR (under "Broken Object Level Authorization") as the #1 risk.
Examples
- CVE-2019-5418 — Rails File Content Disclosure was technically a path/header bug, but the IDOR pattern is broader than any single CVE captures.