Overview
Object-level authorization is the check that a user may access the specific object they are requesting — not just that they are logged in. Its failure, often called IDOR (Insecure Direct Object Reference), is one of the most common real-world web flaws. This lesson focuses on it.
Learning objectives
- Define object-level authorization and IDOR.
- Explain why identifier-based access needs ownership checks.
- Describe defenses against IDOR.
Core concept
Object-level authorization verifies, for each request that references an object (by ID, filename, key), that the requesting identity is allowed to access that particular object. When this check is missing, an attacker can change the reference to point at objects they do not own — an IDOR / broken object-level authorization flaw. It is especially common in APIs, where objects are addressed directly by identifiers.
How it works
Applications routinely expose object references (e.g. /api/documents/57). The vulnerability arises when the server retrieves the object solely from the supplied reference without confirming the requester's rights to it. The defense is to authorize against the object: check that the current user owns or is permitted the requested object (e.g. "this document's owner is the requesting user, or the user has an allowed role"). Using unpredictable identifiers raises the bar but is not a substitute for the authorization check — obscurity alone is not access control.
Practical example
An app serves documents at /api/documents/{id}. A logged-in user requests their document 57; by changing the id to 58, they receive another user's document because the server never checks ownership — a textbook IDOR. The fix: before returning document {id}, the server verifies the document belongs to (or is shared with) the requesting user, returning 403/404 otherwise. Random UUIDs instead of sequential IDs make guessing harder but do not replace that ownership check.
Cybersecurity relevance
IDOR / broken object-level authorization is extremely common — particularly in APIs — and high-impact, since it can expose or modify other users' data at scale by simply iterating identifiers. It appears prominently in API-security risk rankings. Testers probe by changing identifiers to access objects they should not; defenders enforce per-object ownership/permission checks on every object-referencing request. This is the concrete mechanism behind much horizontal privilege escalation.
Common mistakes
- Authorizing by "is the user logged in?" instead of "may this user access this object?"
- Relying on unpredictable IDs (UUIDs) as the only defense — obscurity is not authorization.
- Checking ownership on some endpoints but not others that reference the same objects.
Key takeaways
- Object-level authorization checks that a user may access the specific object they reference; its failure is IDOR / broken object-level authorization.
- The flaw occurs when the server fetches an object from the supplied identifier without verifying ownership/permission.
- Defend by enforcing per-object ownership/permission checks on every object-referencing request; unpredictable IDs help but do not replace the check.
Check your understanding
- What does object-level authorization verify that a simple "is the user authenticated?" check does not?
- Why are unpredictable identifiers (like UUIDs) insufficient on their own to prevent IDOR?