Fugas de datos cross-tenant

Tenant isolation is one of those things that works perfectly until the moment it doesn't, and the moment it doesn't is the moment that ends up in the security write-up. The bug looks small in any single query — one missing `WHERE tenant_id = ?` clause buried in a code path that gets hit twice a week by an admin export feature — but the consequence is unbounded: every customer's data is reachable from every other customer's session. B2B SaaS lives or dies on tenant isolation; a cross-tenant leak isn't a bug report, it's a board-level incident with regulator letters and customer churn. The structural defense is well-understood; the operational discipline of getting it on every code path is what's hard.

Tenant-isolation issues appear when a multi-tenant app checks authentication but not the tenant boundary for every object and action. The result can be cross-customer read or write access.

Customer data leak across orgs — emails, billing info, internal documents, integration tokens, anything the leaking tenant stored. Trust impact in B2B SaaS is severe and lasting; one cross-tenant incident is the kind of thing that makes its way into RFPs as 'have you ever experienced a cross-tenant breach.' GDPR exposure escalates dramatically (controller-level breach affecting multiple data subjects across multiple legal entities). Customer churn after disclosure is real and large.

Enforce tenant filtering at the data-access layer, not at every controller. The right pattern: ORM scopes that automatically apply `currentTenant.id` to every query (Mongoose middleware, Sequelize defaultScope, Drizzle row-level security helpers, Prisma extensions). The strongest version: Postgres Row-Level Security policies that the database itself enforces — your application code becomes incapable of forgetting. Every query that crosses the tenant boundary intentionally (admin tools, customer-support views, internal reports) is explicit and reviewed. Bind tenant scope to the session at the auth layer, never read it from request input. Write integration tests that authenticate as tenant A, create a uniquely-marked resource, then authenticate as tenant B and assert the resource is invisible — bake this into your test fixture so every endpoint is automatically covered. Audit your codebase for `findById`, `findOne` patterns that don't include the tenant predicate; those are the bugs waiting to ship.

Tenant isolation is the quintessential 'one missing line' vulnerability — and the right defense is to make that line impossible to miss. RLS policies and ORM scopes shift the responsibility from developer discipline to platform enforcement. Don't rely on discipline.