IDOR Exploitation Analysis
A file-download endpoint accepted predictable integer identifiers and trusted them implicitly. Authenticated users could enumerate identifiers and download files belonging to other tenants — a textbook Broken Access Control issue with very real business impact.
Findings
The vulnerable endpoint accepted a numeric file identifier in the URL path and returned the file bytes without checking whether the identifier belonged to the authenticated principal:
GET /api/files/47812/download
Cookie: session=<valid-session>
200 OK
Content-Disposition: attachment; filename="other-tenant-export.csv"Identifiers were sequential and predictable, which meant trivial enumeration via Burp Intruder recovered files belonging to other tenants in bulk.
Business Impact
- Cross-tenant data exposure (regulated personal data, contracts, internal documents).
- Compliance impact under data protection regulations (data breach notification triggers).
- Reputational risk — the endpoint was reachable by any authenticated user.
- Long-tail risk — historical files remain enumerable until rotated.
Remediation
- Enforce server-side authorization that binds the requested object ID to the authenticated principal — never trust the client-supplied ID alone.
- Move from sequential integers to unguessable identifiers (UUIDv4) for new objects.
- Implement object-level access control as a centralized policy layer rather than per-endpoint checks.
- Add log + alert on authorization failures spiking from a single principal — early IDOR enumeration shows up here first.
- Run an authorization review across every endpoint that accepts an object identifier — IDOR rarely lives alone.