Brief #10 · Security
Multi-Tenant Data Isolation
Medium⏱ 10-14 hSoon
Find and close the bug that lets one company read another company's invoices by changing a number in the URL.
Outlines are free · building with tracking needs Pro
MThe briefFrom the team
We sell an invoicing tool to many small businesses on one database. A security researcher emailed us: logged in as Company A, they opened /invoices/1042 and saw Company B's invoice. This is broken object-level authorization, the number one API risk. Fix it everywhere, and make sure it can't come back.
What you'll build
- 1A small multi-tenant API (tenants, users, invoices) that starts out vulnerable on purpose.
- 2Write the exploit as an automated test: user A reads, edits and deletes tenant B's data.
- 3Fix it in the application layer: every query scoped by the tenant from the token.
- 4Add a second wall with PostgreSQL row-level security.
- 5Return 404, not 403, for other tenants' IDs, and explain why.
Step-by-step walkthrough
Walkthrough coming soon
This project's step-by-step walkthrough, with real outputs at every step, is still being written. You can read the brief and try it on your own meanwhile; tracking opens when the walkthrough is ready.
Done when
- Every exploit test now fails to access other tenants' data.
- With the app-level check removed, RLS still blocks the read.
- A test fails CI if any new endpoint skips the tenant check.
- A short report in the style of a security advisory.
Stretch goals
- Roles inside a tenant (admin, accountant, viewer) with a policy table.
- Swap sequential IDs for UUIDs and explain why that alone isn't a fix.