Sample write-up. This case study is a placeholder illustrating the format and depth of a real engagement report. Replace with an anonymized, disclosure-approved write-up from an actual engagement once available.
IDOR in a Multi-Tenant SaaS API
How a predictable object ID in a REST endpoint allowed cross-tenant data access, and the fix that closed the gap.
Context
[PLACEHOLDER — Client industry, e.g. "a B2B SaaS platform serving mid-market finance teams"] engaged a web and API assessment ahead of a SOC 2 renewal. The API in scope served account and billing data to multiple tenant organizations through a single shared backend.
Finding
The GET /api/v1/invoices/{'{'}invoice_id{'}'} endpoint accepted a sequential integer ID and returned invoice data without verifying that the requesting user's tenant matched the invoice's owning tenant. Incrementing the ID by one returned another customer's invoice, including line items and billing contact details — a textbook Broken Object-Level Authorization (BOLA/IDOR) issue.
Impact
Any authenticated user on the platform could enumerate and read billing records belonging to any other tenant, exposing customer names, contract values, and billing emails across the entire customer base — a severe confidentiality breach with regulatory implications under most data-protection frameworks.
Proof of concept (redacted)
[PLACEHOLDER — request/response excerpt showing the ID increment and cross-tenant data returned, redacted of real customer data]
Remediation
The fix enforced a tenant-scoped authorization check on every object fetch: the API now verifies the invoice's tenant_id against the authenticated session's tenant before returning data, and object IDs were migrated to non-sequential UUIDs to remove easy enumeration as a secondary defense layer.
Severity
CVSS 3.1: 8.1 (High) — Confidentiality: High, Integrity: None, Availability: None, Attack Complexity: Low, Privileges Required: Low.