A multi-tenant API serves many separate customers — companies, teams, or organisations, usually called tenants — from one shared codebase and, almost always, one shared database. That sharing is what makes multi-tenant systems economical to run: one deployment, one schema, one set of servers, instead of provisioning a separate stack per customer. It's also exactly why a single missing check can be catastrophic in a way a single-tenant system's equivalent mistake isn't — every query in a multi-tenant system touches a table holding every tenant's data at once, and the only thing standing between tenant A's request and tenant B's rows is whichever code path is supposed to filter by tenant.
This is BOLA's tenant-scale cousin, and the two are worth distinguishing precisely: BOLA is about one object belonging to the wrong user; a multi-tenancy isolation failure is about an entire tenant's data — every object, every table, potentially every row an attacker's queries can reach — becoming visible to a different tenant because the isolation boundary itself, not just one object's ownership check, was never enforced. The blast radius of a BOLA bug is one object; the blast radius of a tenant isolation failure is an entire customer's data, and often every customer's data at once.
The core discipline is making tenant scoping impossible to forget rather than merely correct when someone remembers it: every query that touches tenant-owned data should be structurally incapable of returning another tenant's rows, whether through database-level enforcement, an application-layer scoping requirement baked into the data-access layer, or — for the highest-sensitivity cases — physical separation at the database or schema level.
This lesson covers the spectrum of isolation strategies from cheapest to most rigorous — shared schema with a tenant-ID column, schema-per-tenant, and database-per-tenant — and the specific, structural techniques (row-level security, connection-level tenant context, mandatory scoping in the ORM) that make the cheapest option, the one almost every growing system actually uses, trustworthy rather than merely convenient.