Insecure Direct Object Reference (IDOR)
An endpoint exposes object identifiers but fails to verify that the caller is authorized for that specific object.
Overview
When access control checks the user is authenticated but not that they own the referenced id, changing an id (numeric, UUID, or filename) returns or modifies another tenant’s data. It is the #1 API risk (BOLA).
How it works
When access control checks the user is authenticated but not that they own the referenced id, changing an id (numeric, UUID, or filename) returns or modifies another tenant’s data. It is the #1 API risk (BOLA).
Example
Impact
Cross-tenant data disclosure and tampering, mass data scraping, and privilege escalation.
Detection
Authenticate as two users and replay each one’s object references with the other’s session, flagging any successful cross-account read or write. Diffing the actual response content, rather than just checking the status code, is what confirms real data exposure instead of a coincidental 200.
Prevention
- Enforce per-object authorization on every request, server-side.
- Scope queries by the authenticated principal (WHERE owner_id = :me).
- Use unpredictable identifiers as defense-in-depth, never as the control.
- Add automated multi-tenant authorization tests to CI.