Quick answer: A multi tenant application serves more than one customer (tenant) from a single application and database; each customer's data is logically separated but physically sits in the same system. The only thing that usually enforces this separation is a tenant number (a tenant id, a property id) and if this number is carried openly in the request and the server does not check on every call whether the caller actually belongs to that tenant, a tenant can simply change this number and reach another customer's data. This class of flaw is called multi tenant IDOR (Insecure Direct Object Reference) or BOLA (Broken Object Level Authorization) and is especially dangerous because it can affect many customers at once, at automated scale.

As a SaaS product grows, setting up a separate server for every customer becomes expensive and hard to manage. Instead, almost every modern SaaS product shares a single application and a single database across thousands of customers; this is called a multi tenant architecture. The entire security of this architecture depends on the boundary between tenants being drawn correctly on every single request.

Where the problem appears

In a multi tenant system, an API request usually looks like this: GET /api/menus?propertyId=23. When the server receives this request it needs to check two separate things: first, does a record with propertyId=23 exist; second, is the caller actually authorized for propertyId=23. In many real world incidents the developer only implements the first check; it looks whether the record exists, not who is asking. As a result, when propertyId is tried in sequence as 1, 2, 3, the system returns a different customer's data every time, as is.

Check type What it asks Result if missing
Existence check Does this record exist Usually always implemented
Authorization check Can this caller access this record If missing, cross tenant data leak

Why it is especially dangerous

A classic IDOR flaw usually affects a single user's data; a multi tenant IDOR can affect the entire customer base because a tenant number is usually a small, predictable integer, and a single loop can scan dozens or even hundreds of tenants. The type of data leaked also matters: sometimes only public marketing content leaks, while in other cases financial account information, customer personal data or business sensitive information can leak. This distinction directly determines whether a finding should be rated low or critical; just as with general IDOR and broken access control flaws, impact must always be measured by the type of data, not merely by the existence of the flaw.

Typical shapes of the finding

This class of flaw usually repeats not on a single endpoint but across multiple endpoints that share the same tenant number: content and menu services, search and inventory services, payment and billing information services, and even login services can behave differently based on tenant number, and this behavioral difference alone can reveal which tenant numbers actually exist. This is why during an API security test verifying a single endpoint is not enough; all endpoints sharing the same parameter pattern must be systematically scanned.

How to prevent it

The fix is architectural: tenant identity should never be determined solely by trusting a parameter coming from the request, it should be derived from the session or the authentication token. Every database query should enforce this verified tenant identity as a mandatory filter; in many modern frameworks this can also be enforced at the database layer with row level security. This approach applies the least privilege principle, often seen in cloud security assessments, at the API level.

The KAOS and DSET approach

DSET systematically tests tenant isolation in shared SaaS infrastructures, not with a single request but with differential proof obtained by repeating a parameter with different values. Our local AI engine KAOS automatically tries an endpoint with different tenant identities, compares the returned content, and separates a real cross tenant leak from a hypothesis by reporting it with live evidence. Impact level is assessed separately based on the nature of the leaked data, whether public content, financial information or personal data; both overstating a finding as critical and underestimating a real risk are equally wrong.

Frequently asked questions

What is the difference between multi tenant IDOR and classic IDOR? Both rely on the same basic logic: changing an identifier to access someone else's data. The difference is in scale; a classic IDOR usually targets a single user, while a multi tenant IDOR becomes open to systematically scanning the entire customer base because a tenant number is small and predictable.

If the leaked data is public content, is this really a vulnerability? Yes, but its impact is low. The problem is not only the confidentiality of the data but that the system's authorization check is not working at all; if financial or personal data is added tomorrow to an endpoint that returns public content today, the same flaw turns into a much more serious leak. This is why even a low impact example must be fixed at its root cause.

How are these flaws detected? The most reliable method is systematically changing the parameters of a request made with a real, authorized account and comparing the results. Static code review can catch some cases, but the real proof comes from actual, comparable responses obtained from the running system with different tenant identities.

Sources

To test the tenant isolation of your multi tenant system, contact DSET. We provide API and SaaS security consulting from our Ankara Hacettepe Teknokent laboratory.