Tenant isolation

Almost every SaaS product is multi-tenant: one running application and one database serving every customer, with a column somewhere recording who owns each row. Tenant isolation is the set of controls that makes sure that column is always honoured.

There are three common models. Shared schema puts every tenant in the same tables, separated by a tenant identifier. Schema per tenant gives each customer its own set of tables in one database. Database per tenant gives each customer its own database. Cost and operational effort rise across that list, and so does the strength of the separation.

The distinction that matters is where the rule is enforced. If isolation depends on every query in the application remembering to filter by tenant, then one forgotten filter in one endpoint leaks data across customers. If the database refuses to return another tenant’s rows no matter what it is asked, a coding mistake produces an empty result instead of an incident.

A failure here is a case of broken access control, which sits first on the OWASP Top 10. Cross-tenant leaks are among the few software failures that can end a company outright. They are individually reportable, they are visible to the customer who receives the wrong data, and they are almost impossible to explain away.