---
term: 'Tenant Isolation in Shared Cloud Databases'
seoTitle: 'What is Tenant Isolation? Shared Cloud Databases Explained'
headline: 'What is Tenant Isolation?'
slug: tenant-isolation
category: database
shortDefinition: 'Tenant isolation is a discipline of walls inside shared systems — controls that keep every tenant sealed off from every other tenant.'
relatedTerms:
  - multi-tenant-database-architecture
  - row-level-security
  - access-control-lists-acl
  - data-encryption-at-rest-transit
  - multi-tenant-cloud-hosting
contrastsWith:
  - multi-tenant-database-architecture
faq:
  - question: 'What is tenant isolation?'
    answer: 'The set of architectural controls that prevent one tenant in a shared system from reaching another tenant''s data or resources — the walls between apartments in a shared building. It spans every layer that is shared: database rows, caches, queues, file storage, and compute, each needing its own boundary scoped to the current tenant.'
  - question: 'How is tenant isolation different from authentication and authorization?'
    answer: 'A user can be fully authenticated and correctly authorized for their role — and still reach another tenant''s data if nothing scopes the query. Authentication proves who you are; authorization decides what actions you may take; isolation guarantees which tenant''s universe those actions happen in. It is a separate layer, and treating login plus roles as sufficient is the root of most cross-tenant bugs.'
  - question: 'What causes cross-tenant data leakage?'
    answer: 'A short, stable list: queries missing their tenant filter; IDOR — guessable IDs fetched without tenant scoping; background jobs, webhooks, and exports running outside tenant context; caches keyed without the tenant; analytics and reporting pipelines that bypass application checks; and trusting a client-supplied tenant identifier instead of deriving it from the session server-side.'
  - question: 'Is the noisy neighbor problem the same as tenant isolation?'
    answer: 'They are siblings, not the same problem. Security isolation prevents one tenant accessing another''s data; performance isolation — the noisy neighbor problem — prevents one tenant''s workload degrading everyone else''s, and is solved with quotas, throttling, and partitioning. Discussions regularly conflate them; a system can be perfectly secure and still let one tenant starve the rest.'
  - question: 'Which isolation model do compliance frameworks require?'
    answer: 'None of the major frameworks mandates an architecture — they are outcome-based, requiring appropriate and demonstrable measures. Physical separation is typically driven by enterprise customers and contracts, not regulators. What audits do reward: enforcement at the data layer, documented boundaries, and evidence that isolation is tested rather than assumed.'
  - question: 'How does row-level security enforce tenant isolation?'
    answer: 'By making the tenant boundary a property of the table: policies filter every query by the session''s tenant context, so a query that forgets its filter returns nothing instead of everything. The equivalent in document databases is per-object access control — ACLs naming the tenant role — enforced by the platform on every request. Either way, the wall stands even when application code stumbles.'
  - question: 'How do you test tenant isolation?'
    answer: 'Adversarially, with two tenants: swap object IDs across them on every endpoint (the IDOR probe), replay one tenant''s token against the other''s resources, exercise the paths that skip the main app — exports, admin panels, background jobs — and inspect cache keys and file URLs for missing tenant scope. Automate the negative tests in CI; isolation that is not tested is a hypothesis.'
  - question: 'What layers need isolation besides the database?'
    answer: 'Everything shared: cache keys prefixed by tenant, queue topics and consumer groups scoped per tenant, object storage under per-tenant prefixes with matching access policies, per-tenant encryption keys where contracts demand them, and tenant claims carried in tokens and validated on every request. The database wall is necessary, never sufficient.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'OWASP Multi-Tenant Security Cheat Sheet'
    url: 'https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html'
  - name: 'PostgreSQL Row Security Policies'
    url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html'
  - name: 'OWASP Cloud Tenant Isolation project'
    url: 'https://owasp.org/www-project-cloud-tenant-isolation/'
  - name: 'Row-Level Security and Multi-Tenancy on MongoDB (Back4app Engineering)'
    url: 'https://www.back4app.com/multi-tenant-mongodb-row-level-security'
cta:
  title: 'Walls that hold on every request'
  text: 'Back4app enforces tenant boundaries in the data layer: roles define the tenant, ACLs seal every object to it, and class-level permissions gate the schema — checked server-side on every SDK call, API request, and dashboard edit.'
  linkText: 'Start Free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-25'
translationKey: tenant-isolation
---

**Tenant isolation is a discipline of walls inside shared systems — controls that keep every tenant sealed off from every other tenant.** The point most explanations bury deserves the first paragraph: isolation is *not* authentication or authorization. A perfectly logged-in, correctly-roled user can still read a competitor's data if nothing scopes the query — isolation is the third layer that decides *whose universe* every operation happens in.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | The guarantees that no tenant can reach another tenant's data or resources |
| Not to confuse with | Authentication (who) and authorization (what) — isolation is *whose* |
| Where walls belong | Database rows, caches, queues, storage, tokens — every shared layer |
| The failure mode | One unscoped query, job, or cache key = cross-tenant leak |
| The standard | Enforce in the data layer; test adversarially; never trust client-sent tenant IDs |

## The bug, and the wall that survives it

```sql
-- The bug isolation exists to survive: a query that forgot its tenant
SELECT * FROM invoices WHERE id = $1;        -- returns anyone's invoice

-- With the wall in the data layer, the same bug returns nothing:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_wall ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);
```

In document databases the wall is built from roles and per-object access control — the tenant is a role, and every row is sealed to it at write time:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Provisioning a tenant boundary: a role is the tenant, membership is access
const tenantRole = new Parse.Role('tenant-acme', new Parse.ACL());
tenantRole.getUsers().add(adminUser);
await tenantRole.save();

// Every acme row from now on: readable and writable by the role only
const doc = new Parse.Object('Project', { name: 'Q3 Launch' });
const acl = new Parse.ACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Every tenant row: readable and writable by the tenant role only
final acl = ParseACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);

final doc = ParseObject('Project')
  ..set('name', 'Q3 Launch')
  ..setACL(acl);
await doc.save(); // invisible to every other tenant, enforced server-side
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Every tenant row: readable and writable by the tenant role only
var acl = ParseACL()
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)

var doc = Project()
doc.name = "Q3 Launch"
doc.ACL = acl
doc.save { _ in } // invisible to every other tenant, enforced server-side
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Every tenant row: readable and writable by the tenant role only
val acl = ParseACL().apply {
  setRoleReadAccess("tenant-acme", true)
  setRoleWriteAccess("tenant-acme", true)
}
val doc = ParseObject("Project").apply {
  put("name", "Q3 Launch")
  setACL(acl)
}
doc.saveInBackground() // invisible to every other tenant, enforced server-side
```

## The enforcement stack

```mermaid
flowchart TB
  accTitle: Layered tenant isolation enforcement
  accDescr: Tenant context is established in the session token, scoped in application queries, enforced by data-layer policies or ACLs, and separated at the infrastructure layer through namespaced caches, queues, storage prefixes, and keys.
  T["Token layer<br/>tenant claim in the session — never client-supplied"]
  A["Application layer<br/>queries scoped by tenant context"]
  D["Data layer<br/>RLS policies / per-object ACLs — the wall that holds"]
  I["Infrastructure layer<br/>namespaced caches, queues, storage prefixes, keys"]
  T --> A --> D --> I
```

Each layer catches what the one above drops: the token establishes tenant identity server-side, application code scopes by habit, the data layer enforces by policy, and the infrastructure namespaces everything else that's shared. The [OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) is the canonical checklist for the full stack.

## Isolation vs. authentication vs. authorization

| Question answered | Mechanism | Failure looks like |
| --- | --- | --- |
| Who are you? (authentication) | Login, sessions, tokens | An impostor gets in |
| What may you do? (authorization) | Roles, permissions | A user exceeds their role |
| **Whose data is this? (isolation)** | Tenant scoping + data-layer walls | **A valid user reads another tenant** |

The third row is the one that produces headlines, because it passes every test the first two rows define: the attacker logs in legitimately, uses permitted operations — and walks through a missing wall. The cloud era's canonical cross-tenant vulnerabilities (the ChaosDB class of research findings, where one tenant could derive access to others' databases) were all third-row failures in systems with impeccable first and second rows.

## Where leaks actually come from

- **The forgotten filter** — one query without its tenant scope; the reason walls belong in the data layer, not in developer memory.
- **IDOR** — sequential or guessable IDs fetched without tenant checks; swap an ID, read a stranger's record.
- **Out-of-context execution** — background jobs, webhooks, scheduled tasks, and data exports running with broad credentials and no tenant context.
- **Unscoped shared services** — cache keys, search indexes, and file paths missing the tenant prefix; the database wall stands while the cache leaks.
- **Sidechannel pipelines** — analytics and reporting reading the database directly, beneath every application check.
- **Client-trusted tenancy** — a tenant ID accepted from the request body instead of derived from the session; the politest possible way to hand out other tenants' data.

## Security isolation vs. noisy neighbors

Same word, two problems. *Security* isolation keeps tenant A out of tenant B's data. *Performance* isolation keeps tenant A's bulk import out of tenant B's checkout latency — solved with quotas, rate limits, and partitioning, and covered on the [architecture side of this topic](/glossary/multi-tenant-database-architecture/). A system can be watertight and still let one tenant starve the rest; budget for both, and don't let a quota discussion masquerade as a security review.

## Testing tenant isolation

The two-tenant adversarial pass, automated in CI: create tenants A and B, then attempt every crossover — B's object IDs through A's session on every endpoint (the IDOR sweep), A's token against B's resources, the off-path surfaces (exports, admin panels, jobs) with each tenant's context, and an inspection of cache keys, file URLs, and search results for missing tenant scope. Add the unset-context case: no tenant in session should mean *no rows*, never *all rows*. Isolation that hasn't been attacked in CI is a hypothesis with a compliance certificate.

## Common use cases

- **B2B SaaS.** Every workspace is a tenant; isolation is the product promise underneath every feature.
- **Platforms hosting customer apps.** Two altitudes at once — the platform isolates apps from each other, each app isolates its own tenants.
- **Enterprise and regulated tiers.** Contractual isolation demands mapped to stronger walls — per-tenant keys, dedicated resources — for the accounts that require them.
- **Agencies and white-label products.** One deployment, many client organizations, each sealed.
- **Internal multi-team platforms.** Departments as tenants; friendlier threat model, identical mechanics.

## How much isolation? A decision matrix

| Pooled + data-layer walls when… | Stronger separation when… |
| --- | --- |
| Many small tenants, standard sensitivity | Contracts name isolation requirements |
| Cost per tenant must stay near zero | A tenant's data demands its own keys or region |
| Walls are enforced (RLS/ACLs) and tested | Blast-radius arguments beat density economics |
| One update cycle should cover everyone | Per-tenant restore is a promised feature |
| The team can maintain adversarial tests | Auditors want boundaries they can point at |

The honest framing: pooled with enforced, tested walls is legitimate isolation — most of the industry runs on it. Move individual tenants up the separation ladder when their requirements, not fashion, demand it.

## Limitations and trade-offs

- **Isolation is cross-cutting forever.** Every new feature — cache, queue, export, search — re-asks the tenancy question; the discipline never finishes.
- **Data-layer walls have operational fine print.** Session context vs. connection pooling, policy bypass roles, and dump modes — the [row-level security entry](/glossary/row-level-security/) catalogs them.
- **Shared blast radius survives correctness.** Perfect logical isolation still shares failure domains — one bad deploy touches every tenant; only physical separation changes that.
- **Testing is the unbudgeted cost.** The two-tenant suite is real engineering; skipping it converts "enforced" back into "assumed."
- **Stronger walls cost density.** Per-tenant keys, silos, and dedicated resources all trade the economics that made sharing attractive — spend them on the tenants that need them.

## Tenant isolation on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Isolation is data-layer-first by construction: roles define the tenant, every object's ACL seals it to that role, and class-level permissions gate the schema — enforced server-side on every path, SDKs, REST, GraphQL, and dashboard alike, so the forgotten-filter bug has nothing to forget. The platform itself applies the same discipline one level up, isolating each app's backend from every other's — and the [engineering deep-dive on row-level security](https://www.back4app.com/multi-tenant-mongodb-row-level-security) shows the full pattern in practice.