Home / Knowledge hub / Tenant data leak
Knowledge hub
Tenant data leak
One customer seeing records that belong to another customer of your service.
What it means
A tenant data leak is when one customer of a multi-tenant service can see or change another customer's data. In a shared app, many organisations use the same code and often the same database. A tenant is one of those organisations, and the app must keep their data apart.
The leak is a failure of that separation. One missing filter, such as a query that selects by record id without adding the tenant id, is enough. The user is a legitimate customer; they are just looking at the wrong tenant's records.
Why it matters
For a business-to-business product it is among the worst things that can happen. Contracts, security questionnaires and data-protection law all assume you keep customers apart. A leak can trigger breach notification, loss of the affected customers, and questions from every other customer.
The scale is the real problem. A single flaw in a shared query can expose all tenants, not one person's record. It can also go unseen for a long time, as the leaking customer simply sees extra rows and may not report it.
How it shows up
Leaks come from queries without a tenant filter, shared caches whose keys omit the tenant, search indexes and exports built across tenants, background jobs that run without a tenant context, file storage with guessable paths, and admin tools that switch tenants without a check.
Defences work at several layers: pass tenant context from the signed-in session, not from the request; add the tenant to every query through a shared data layer or database row-level security; scope cache keys and storage paths by tenant. Test with two tenants and compare, and see [[tenant-isolation]].
Questions people ask
Tenant data leak, answered
What is a tenant in a SaaS product?
A tenant is one customer organisation using your shared service, with its own users and data. The app must treat each tenant as a separate boundary.
Is a tenant leak the same as IDOR?
IDOR is one common cause. A tenant leak describes the outcome, one customer seeing another's data, whatever the technical flaw was.
Does using separate databases remove the risk?
It lowers it, since there is no shared table to query wrongly. But shared caches, queues, storage, search and admin tools can still cross tenants, so the other layers still need testing.
Where should the tenant id come from?
From the server's record of the signed-in session, not from a value the client sends. A tenant id in a request is something an attacker can change.
How do we test for tenant leaks?
Create two tenants with distinct data, sign in to one, and try every route with the other's ids and paths. Also check exports, search, cached pages and file links.
Sources
Where this comes from
Related
Terms that sit next to this one
Tenant isolation
What keeps one customer's data unreachable from another's session.
Multi-tenancy
One running application serving many customers whose data must stay apart.
Row-level security
Database rules that limit which rows each account can read or change.
Cross-account access
One signed-in account reaching another account's data or functions.
Data breach
Information you hold ends up somewhere it should not be.
Can one customer see another's records?
We test your app with separate customer accounts and report cross-account access we actually reached, with the request, the response and a screenshot. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.