FixVibe

// probes / spotlight

Cross-Tenant Data Leaks

Multi-tenant SaaS without tenant ID enforcement leaks customer data across orgs.

What it is

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.

How it happens

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.

What an attacker gets

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.

// what fixvibe reports

What FixVibe reports

Runs in active scans of a domain you have verified you own, on Hobby and above. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.

How to fix it

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.

Key takeaway

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.

// run it on your own app

Sen yayınlamaya devam et, FixVibe gözcülüğü üstlensin.

Verify you own the domain, then run active checks alongside the passive ones.

Aktif problar
138
bu kategoride çalıştırılan testler
modules
58
aktif problar için özel check’ler
verified domains
130+
active checks after verification
Verify your domain →

// latest checks · practical fixes · ship with confidence

Cross-Tenant Data Leaks: what it is and how to fix it · FixVibe