Why Isn’t Authentication Enough to Prevent Cross-Tenant Data Leaks?

A user signs in successfully. Their JWT is valid, their session is active, their role says they are an administrator, and they call an API endpoint they are allowed to use.

The application still returns data belonging to another customer.

Nothing about that scenario requires authentication to be broken. That is what makes multi-tenant authorization bugs so dangerous: identity can be completely correct while resource scope is wrong.

This distinction became much more concrete to me while building a multi-tenant marketplace backend. Once one application serves several organizations through shared APIs, services, caches, databases, queues, and infrastructure, the security question changes from simply asking:

“Who is this user?”

to asking:

“Which tenant is this request allowed to affect, and where is that boundary enforced?”

Those questions sound similar, but they describe different guarantees. Authentication establishes identity. Authorization determines what an identity may do. Tenant isolation constrains whose resources that action may touch.

If tenant context is missing, stale, client-controlled, inconsistently propagated, or forgotten in one data-access path, every request can authenticate correctly and the system can still leak information between organizations. AWS makes the same distinction in its SaaS architecture guidance: authentication and ordinary authorization do not by themselves guarantee that a caller is operating inside the correct tenant boundary.

That makes tenant isolation less like a feature and more like an invariant.

And important invariants should not depend on every developer remembering to add one more tenant_id predicate.

The Three Questions We Often Collapse Into One

Consider this request:

GET /organizations/org_b/orders/order_921
Authorization: Bearer <token>

There are several security decisions hiding inside it:

Authentication answers the first question. A role or permission model may answer the second. Tenant isolation depends on the third and fourth remaining true throughout the entire request path.

OWASP describes one common version of this failure as Broken Object Level Authorization, or BOLA. An authenticated user manipulates an object identifier and reaches another user's resource because the application verified access to the endpoint but not authorization for the specific object.

A UUID does not fix that.

Neither does an unguessable organization ID.

Opaque identifiers may make accidental discovery harder, but secrecy of an identifier is not an authorization boundary.

The Dangerous Version of Multi-Tenancy

Suppose an endpoint looks like this:

@Get(":organizationId/orders/:orderId")
async getOrder(
  @Param("organizationId") organizationId: string,
  @Param("orderId") orderId: string,
) {
  return this.ordersService.findById(orderId);
}

The route contains an organization identifier, but that identifier does not actually constrain the resource being fetched. The service looks up an order by ID alone.

If a caller belonging to Organization A learns the ID of an order owned by Organization B, the route structure itself does nothing to prevent the lookup.

A first fix might be:

const order = await this.ordersService.findById(orderId);

if (order.organizationId !== organizationId) {
  throw new ForbiddenException();
}

return order;

That is better, but the security property now depends on every caller remembering to perform exactly the same comparison after fetching the resource.

As an API grows, that is where authorization drift begins. One controller remembers the check. Another forgets it. A background worker calls the repository directly. A batch operation bypasses the controller. A new developer reasonably assumes the service is already tenant-aware. A cache lookup returns an object before the authorization branch runs.

The failure is rarely:

“Nobody implemented authentication.”

It is more often:

“Tenant context could disappear in several different places, and one of them eventually did.”

That is an architectural problem, not just a missing if statement.

Make Tenant Context a First-Class Value

AWS describes the combination of user identity and tenant identity as part of a broader SaaS identity. The important idea is that tenant association should follow the request through the system instead of being rediscovered independently by every service.

That suggests a useful rule:

Resolve tenant context once, validate it against trusted identity and membership data, then propagate the trusted result.

A NestJS guard might produce something like:

export interface TenantContext {
  tenantId: string;
  userId: string;
  roles: string[];
}

@Injectable()
export class TenantGuard implements CanActivate {
  constructor(private readonly memberships: MembershipService) {}

  async canActivate(context: ExecutionContext) {
    const request = context.switchToHttp().getRequest();

    const userId = request.user.id;
    const requestedTenantId = request.params.organizationId;

    const membership = await this.memberships.findActiveMembership(
      userId,
      requestedTenantId,
    );

    if (!membership) {
      throw new ForbiddenException();
    }

    request.tenant = {
      tenantId: requestedTenantId,
      userId,
      roles: membership.roles,
    } satisfies TenantContext;

    return true;
  }
}

The route parameter has an important meaning here: it is input, not truth.

The client may ask to operate on:

organizationId = org_b

but the system only turns that value into trusted tenant context after verifying that the authenticated caller actually belongs to org_b.

The same is true for a tenant header:

X-Tenant-ID: org_b

Middleware reading that header does not make it trustworthy. Anything supplied by the client still has to be checked against identity and membership information controlled by the server.

Implementation note

The client can propose a tenant context. Only the server should be able to authorize it.

Once that distinction is explicit, downstream services no longer need to wonder whether an arbitrary tenantId is already trusted or merely came from the request.

Scope the Query, Not Just the Controller

Once trusted tenant context exists, the data-access layer should make unscoped resource access difficult to express accidentally.

Instead of:

findOrder(orderId: string) {
  return this.orders.findOne({
    _id: orderId,
  });
}

prefer an interface that requires scope:

findOrder(
  tenant: TenantContext,
  orderId: string,
) {
  return this.orders.findOne({
    _id: orderId,
    organizationId: tenant.tenantId,
  });
}

The code difference is small. The architectural difference is not.

The first function asks:

Which order has this ID?

The second asks:

Which order with this ID exists
inside the current tenant boundary?

Tenant isolation has moved from a convention around the repository to part of the repository's contract.

The same principle applies to writes.

This is weaker:

await orders.updateOne({ _id: orderId }, { $set: { status: "cancelled" } });

This is stronger:

const result = await orders.updateOne(
  {
    _id: orderId,
    organizationId: tenant.tenantId,
  },
  {
    $set: {
      status: "cancelled",
    },
  },
);

if (result.matchedCount !== 1) {
  throw new NotFoundException();
}

Now ownership validation and mutation happen inside one database operation. There is no separate interval where code finds the resource, checks the tenant, and later performs a broader update that can accidentally target something else.

This also gives the system a useful security behavior: a foreign resource can look indistinguishable from a nonexistent one to the caller rather than revealing that the identifier belongs to somebody else.

Tenant Isolation Extends Beyond Reads

Cross-tenant isolation is often summarized as:

User A should not see User B's row.

That is necessary, but it is much too narrow.

Tenant boundaries also apply to:

updates
deletes
search results
aggregations
cache entries
file storage
background jobs
webhooks
rate limits
analytics
logs
exports
notifications

An application can have perfectly scoped MongoDB queries and still leak information through Redis.

Consider this cache key:

const cacheKey = `order:${orderId}`;

The tenant boundary is absent. A safer namespace carries it explicitly:

const cacheKey = `tenant:${tenant.tenantId}:order:${orderId}`;

The same principle applies to object storage:

bad:
orders/order_921.pdf

better:
tenants/org_a/orders/order_921.pdf

And potentially to rate limiting:

global:user:123

may represent a very different policy from:

tenant:org_a:user:123

when one identity can participate in several organizations.

Multi-tenancy therefore has to survive every shared namespace, not just every database query. Any place where tenant-owned state is stored, derived, cached, queued, indexed, or exported is another place where the boundary can disappear.

Tenant Context Must Survive Asynchronous Boundaries

HTTP middleware can create a false sense of safety because the request lifecycle makes trusted context easy to reach.

Then the application queues work:

await jobs.add("generate-report", {
  reportId,
});

Later, the worker receives only:

{
  "reportId": "report_123"
}

What tenant owns that report?

The worker no longer has the HTTP request. It has no route guard and no middleware-populated context. If it performs:

reports.findById(reportId);

then tenant isolation disappeared as soon as the request crossed the queue boundary.

Tenant identity needs to travel with asynchronous execution:

await jobs.add("generate-report", {
  tenantId: tenant.tenantId,
  reportId,
  requestedBy: tenant.userId,
});

The worker should still scope its own access rather than treating possession of that payload as unlimited authority:

const report = await reports.findOne({
  _id: job.data.reportId,
  organizationId: job.data.tenantId,
});

The same class of failure appears in Kafka events, scheduled jobs, webhook processing, delayed tasks, workflow engines, and event-driven systems.

A request can begin tenant-safe and become tenant-unsafe the moment the execution context crosses a process boundary.

That is why tenant identity belongs in the domain execution context, not only in the HTTP request object.

A Valid Token Can Still Carry Stale Authority

Another subtle form of authorization drift appears when too much tenant authority is embedded in a long-lived token.

Suppose a JWT contains:

{
  "sub": "user_123",
  "tenant": "org_a",
  "role": "admin"
}

At 10

At 10

At 10

role = admin
tenant = org_a

JWT signature verification can establish:

This token was issued by us
and has not expired.

It does not automatically establish:

Every authorization fact inside it
is still true right now.

That creates a tradeoff between authorization freshness and request cost.

Short-lived claims reduce the stale window. Server-side membership checks provide fresher information but introduce a database or cache dependency. Revocation infrastructure adds another mechanism to operate. Some applications may reasonably choose different guarantees for different actions: displaying a low-risk dashboard might tolerate slightly older authorization information, while deleting an organization or moving money may justify checking current membership state.

There is no universal answer.

The important part is knowing what guarantee the system is actually making instead of equating a cryptographically valid token with permanently valid authority.

Authorization Drift Is an Architectural Smell

I use authorization drift to describe what happens when equivalent operations slowly acquire different security behavior as a codebase grows.

Imagine these endpoints:

GET    /orders/:id
PATCH  /orders/:id
DELETE /orders/:id

One checks organization membership inside the controller. Another relies on a guard. The third calls a shared service that performs no tenant validation.

During normal testing, all three may appear protected because the common paths use expected inputs. One unusual execution path is enough for the boundary to fail.

GitHub has described using custom CodeQL queries to identify API endpoints and GraphQL operations that fail to define required authorization behavior. I find that approach interesting because it treats missing authorization as something architecture and tooling should detect, rather than something code review should hopefully notice.

The principle generalizes well:

If a security property is important enough, make the architecture or tooling enforce it instead of relying entirely on developer memory.

For a smaller application, that could mean exposing only tenant-aware repository methods:

repository.findByTenant(...)

A larger system might add framework policies, static analysis, database row-level security, policy engines, IAM conditions, or stronger infrastructure isolation.

The specific mechanism can change.

The goal remains the same: the safe path should be easier to write than the unsafe one.

The Database Can Provide Another Boundary

Application-layer tenant filtering is common, especially in pooled multi-tenant applications. It does not have to be the final layer of protection.

PostgreSQL, for example, can enforce tenant policies with Row-Level Security:

CREATE POLICY tenant_isolation
ON orders
USING (
  tenant_id = current_setting('app.tenant_id')
);

Now even an accidentally broad query such as:

SELECT * FROM orders;

can remain constrained by database policy.

That is defense in depth.

It does not remove the need for correct application authorization. It reduces the probability that one forgotten query immediately becomes a cross-tenant incident.

There are real tradeoffs. Database-enforced tenant policies increase operational complexity. Connection pooling has to preserve or reset tenant context correctly. Debugging can become less obvious, and not every datastore provides an equivalent mechanism.

MongoDB-backed systems, for example, may enforce most tenant isolation at the application and repository layers instead.

The broader question matters more than the specific database feature:

If an accidental broad query is written tomorrow, is there another boundary that prevents it from crossing tenants?

A mature isolation model ideally has more than one answer.

Pooled and Siloed Isolation Are Different Tradeoffs

The strongest isolation model would be to give every tenant separate infrastructure:

separate database
separate storage
separate compute
separate credentials

That removes many shared boundaries.

It also introduces substantial operational overhead.

AWS describes this as a silo model, contrasting it with pooled architectures where tenants share infrastructure and isolation is enforced logically. Google Cloud makes a similar distinction when discussing multi-tenant environments: shared application infrastructure improves efficiency, but defects in the shared application layer can expose data across tenants.

The design space is better represented as a spectrum:

No rule says every SaaS product should maximize physical isolation.

A smaller SaaS application may reasonably choose shared compute and a pooled database. A highly regulated or unusually sensitive product may justify separate databases or stronger infrastructure boundaries. Cost, compliance, operational maturity, customer expectations, and scale all affect that decision.

What matters is that the isolation properties are explicit.

"Multi-tenant" describes who shares the product. It does not tell you how strongly the infrastructure separates them.

Centralized Authorization Becomes Critical Infrastructure

Centralizing authorization logic is usually better than duplicating security checks throughout a codebase.

But centralization creates a dependency.

If every important request depends on an authorization service and that service becomes unavailable, the application has to decide what happens next.

GitHub documented an authorization-service incident in 2023 where a memory leak caused authorization requests to fail. Their services failed closed: users received failures rather than the platform bypassing authorization. The incident also exposed an operational dependency because parts of the rollback path depended on the authorization system that was already unhealthy.

That illustrates a real security-versus-availability tension.

A fail-open design behaves like:

authorization unavailable
→ allow request

Availability survives, but the security boundary may not.

A fail-closed design behaves like:

authorization unavailable
→ reject request

Isolation remains intact, but an authorization outage can become an application outage.

For tenant isolation, failing closed is generally the safer security posture because inability to evaluate access should not become permission to cross customer boundaries.

That also means the authorization path deserves production engineering attention:

caching
latency budgets
monitoring
safe rollout
capacity testing
rollback independence

Security infrastructure is still infrastructure. Centralizing policy does not remove reliability work; it makes the reliability of that policy system more important.

A Tenant ID in Every Record Is Necessary, Not Sufficient

A pooled data model commonly looks like:

orders
---------------------------------
id
tenant_id
customer_id
status

That is an important foundation because the database now contains the information required to express ownership.

It does not automatically enforce that ownership.

This query remains unsafe:

SELECT *
FROM orders
WHERE id = $1;

So does this MongoDB lookup:

orders.findOne({
  _id: orderId,
});

Schema design tells the application which tenant owns the resource. Repository or database policy still has to ensure that ownership participates in every relevant operation.

Tenant-aware indexes can also make correct access patterns natural:

await orders.createIndex({
  organizationId: 1,
  _id: 1,
});

The same concept applies to uniqueness.

If a slug only needs to be unique within an organization, this constraint is too broad:

{ slug: 1 } unique

The tenant-aware constraint is:

{
  organizationId: 1,
  slug: 1,
}

Multi-tenancy therefore affects more than security filtering. It changes the definition of correctness for indexes, uniqueness, caches, storage paths, and other data structures as well.

Privileged Cross-Tenant Access Must Be Explicit

Most tenant-scoped operations are conceptually simple:

User belongs to tenant A
→ operate inside tenant A

Then the platform needs support tooling.

An employee may need to investigate several tenants. A migration might process every organization. Analytics may aggregate across customers. A support engineer may need to impersonate or inspect a tenant's environment.

Those are legitimate cross-tenant operations.

They are also exactly where broad rules such as this become dangerous:

role = admin
→ bypass tenant isolation

That gives one ordinary-looking role an enormous and often invisible capability.

A better model makes platform-wide access structurally different:

type AccessScope =
  | {
      type: "tenant";
      tenantId: string;
    }
  | {
      type: "platform";
      reason: string;
    };

Now normal tenant execution and intentional platform execution are separate modes rather than one silently bypassing the other.

Platform access can require stronger auditing, narrower permissions, explicit elevation, time limits, additional approval, or some combination of those controls.

Warning

"Administrator" should not automatically mean "may cross every tenant boundary." Tenant administration and platform administration are different privileges.

The goal is not to pretend cross-tenant access never exists.

The goal is to ensure that it never happens accidentally.

Observability Needs Tenant Context Too

If an isolation incident occurs, investigators need to reconstruct not just the request but the authorization decision around it.

A useful structured event might contain:

{
  "requestId": "req_91f",
  "actorId": "user_123",
  "tenantId": "org_a",
  "resourceType": "order",
  "resourceId": "order_921",
  "action": "read",
  "decision": "allow"
}

A denied request may look more like:

{
  "requestId": "req_91g",
  "actorId": "user_123",
  "requestedTenantId": "org_b",
  "action": "read_order",
  "decision": "deny",
  "reason": "no_active_membership"
}

The point is not to dump sensitive payloads into logs. It is to retain enough security context to answer the questions that matter later:

Which tenant did the request resolve to?

Where did that tenant context come from?

Which policy authorized the operation?

Did the resource actually belong to that tenant?

Was this normal tenant execution or privileged platform access?

Without that information, investigating an isolation failure becomes much harder because the logs may show only that a perfectly authenticated request returned 200.

Observability is part of the security boundary when it determines whether you can explain how that boundary behaved.

How I Would Structure the Boundary

For a pooled SaaS backend, the architecture I want looks roughly like this:

The exact boxes will differ between applications. The important part is the direction of trust:

client-supplied tenant value
          ↓
validate membership
          ↓
trusted tenant context
          ↓
permission decision
          ↓
tenant-scoped resource access

Downstream components should not repeatedly accept arbitrary organization IDs from the outside world and independently decide whether those values are legitimate.

They should consume execution context that has already crossed a defined authorization boundary.

That context can then be carried into repositories, cache namespaces, jobs, storage paths, and any other subsystem that handles tenant-owned state.

Test Tenant Isolation Adversarially

The least interesting tenant-isolation test is:

User A can read User A's order.

Of course they should.

The test that protects the boundary is:

User A cannot read User B's order,
even if User A knows the exact object ID.

And then that idea needs to be repeated across every meaningful execution path.

A useful test matrix might look like this:

OWASP's BOLA guidance encourages exactly this kind of thinking: every endpoint that accepts an object identifier needs object-level authorization, not merely endpoint-level authentication.

The strongest security tests actively try to break the boundary. They substitute valid IDs from another tenant. They alter tenant headers while keeping authentication valid. They feed a worker a mismatched tenant and resource. They verify that cached data cannot bypass repository scoping.

The important question is not:

Does the happy path work?

It is:

What happens when a completely valid user deliberately asks for a completely valid resource that belongs to somebody else?

That is where isolation either exists or it does not.

The Invariant I Want

Ultimately, I want tenant isolation to be expressible as one rule:

No operation may observe or mutate tenant-owned state unless its trusted execution context authorizes that same tenant.

Every architectural choice can then be evaluated against that invariant.

Does the repository preserve it?

Does the cache preserve it?

Does the queue preserve it?

Does a webhook preserve it?

Does object storage preserve it?

Do uniqueness constraints preserve it?

Does a bulk operation preserve it?

Does an administrator cross it only intentionally?

Does a newly added endpoint inherit it by default?

And, most importantly:

Does a developer have to remember to enforce it manually every time?

AWS's SaaS guidance argues for moving isolation enforcement into shared mechanisms rather than depending entirely on individual service developers, because mistakes are inevitable as a codebase and team grow.

That is exactly the direction I want the architecture to move.

Security improves when the unsafe path requires effort rather than the safe path requiring perfect memory.

Authentication Is Only the Beginning

Multi-tenant applications create a deceptively simple illusion.

Everyone signs into the same product. Everyone calls the same API. Their documents may live in the same database. Their cache entries may occupy the same Redis cluster. Their files may share an object-storage bucket. Their requests may run through the same application instances.

Operationally, sharing is the point.

Security-wise, the application has to behave as though invisible walls exist throughout that shared system.

Authentication can tell me:

This is Alice.

Authorization can tell me:

Alice may manage orders.

Tenant isolation still has to guarantee:

Alice may manage orders belonging to Organization A, and nothing in this execution path may silently cross into Organization B.

That guarantee has to survive routing, service calls, repository methods, writes, caches, background workers, webhooks, internal support tools, authorization outages, and code that has not been written yet.

When it does, multi-tenancy stops being a naming convention developers are expected to remember.

It becomes an architectural property of the system.

And that is the level at which tenant security should be designed.

Practical Checklist

• Resolve tenant context from authenticated identity plus validated membership, never from a client-supplied tenant identifier alone.
• Scope reads and writes by tenant at the repository or data-access layer.
• Carry tenant context across queues, events, scheduled jobs, and other asynchronous boundaries.
• Include tenant identity in cache keys, object-storage paths, uniqueness constraints, and other shared namespaces where appropriate.
• Treat authorization claims as potentially stale and define how quickly membership and role changes must take effect.
• Prefer shared enforcement mechanisms over hand-written checks scattered across controllers.
• Add defense in depth where the datastore or infrastructure supports it.
• Test with valid identities attempting to access valid resources owned by the wrong tenant.
• Make privileged cross-tenant access explicit and auditable.
• Preserve enough tenant and authorization context in structured logs to explain why a decision was allowed or denied.

References

• AWS Well-Architected SaaS Lens — Tenant Isolation and SaaS Identity. AWS distinguishes ordinary authentication and authorization from explicit tenant isolation and recommends making tenant context a first-class part of SaaS identity.

• AWS Prescriptive Guidance — Multi-tenant SaaS authorization and API access control. Discusses scenarios where an authenticated and otherwise authorized user can still access another tenant's resources when isolation is not explicitly enforced.

• OWASP API Security Top 10 — API1

  Broken Object Level Authorization. Describes the common failure mode where authenticated callers manipulate resource identifiers to access objects they do not own.

• GitHub Engineering — How GitHub uses CodeQL to secure GitHub. Describes custom static-analysis rules used to identify API and GraphQL definitions that are missing required authorization methods.

• GitHub Availability Report — November 2023. Documents an authorization-service failure that illustrates the reliability implications of centralized, fail-closed authorization infrastructure.

• Google Cloud — GKE architectures for hosting SaaS applications. Discusses multi-tenant infrastructure models and the risk that bugs in application-layer isolation can expose data across tenants.