Mandantentrennung überprüfen

Tenant Isolation Verification

When to Use

Use during implementation, review, diagnosis, and testing of any multi-tenant feature, endpoint, query, background worker, file handler, or AI tool.

Why Single-Tenant Tests Never Prove Isolation

A test suite that creates Tenant A and asserts Tenant A can read and update its own records proves zero tenant isolation—a query completely missing WHERE tenant_id = ? passes every single-tenant test!

• Mandatory Two-Tenant Rule: Every tenant-scoped feature must be tested with at least two distinct workspaces (Tenant A and Tenant B) seeded with identically shaped resources (and overlapping slugs/names where permitted).

The Adversarial Cross-Tenant Test Matrix

Verify and assert all six isolation vectors in automated tests:

1. Direct IDOR / BOLA Read & Mutation Attempts

• Cross-Tenant Read: Authenticate as a valid member/owner of Tenant A (with active context tenantId = A) and request GET /projects/<projectId_of_Tenant_B> $\rightarrow$ must return 404 Not Found (or 403), never Tenant B's data.
• Cross-Tenant Update / Delete: Authenticate in Tenant A and send PATCH or DELETE targeting <resourceId_of_Tenant_B> $\rightarrow$ must reject and leave Tenant B's row untouched in the database.
• Tenant Header / URL Spoofing: Authenticate as User 1 (member of Tenant A, not Tenant B) and pass X-Workspace-Id: <Tenant_B> or /w/<Tenant_B>/... $\rightarrow$ must fail membership verification (403/404) before reaching the controller.

2. Cross-Tenant Relational Injection (Confused Deputy Joins)

• Authenticate in Tenant A and create or update a record in Tenant A while passing a foreign key ID (parent_id, category_id, assignee_id, file_id, webhook_id) belonging to Tenant B in the request payload:
  • Example: POST /w/tenant-a/tasks { title: "x", projectId: "<project_in_tenant_b>" }.
  • Verify the server validates that every referenced foreign key belongs to Tenant A (backed by composite FKs in the DB) and rejects the request.

3. List, Search, Aggregation & Export Leakage

• Seed matching records in both Tenant A and Tenant B.
• Call list endpoints, search/autocomplete queries, dashboard count/sum aggregations, and CSV/PDF exports as Tenant A $\rightarrow$ assert the response contains exclusively Tenant A records and zero Tenant B records.

4. Missing / Undefined Tenant Context Fail-Closed Check

• Call repository/service methods with tenantId: undefined or empty context $\rightarrow$ assert they throw an explicit error rather than falling back to an unfiltered query.

5. Concurrent Interleaved Request Isolation

• Fire concurrent requests (Promise.all) for Tenant A and Tenant B simultaneously against the same server/worker instance $\rightarrow$ verify zero context bleed across pooled DB connections, AsyncLocalStorage, or shared caches.

6. Revocation & Workspace Switch Verification

• Verify that after removing a user from Tenant A (or switching active workspace to Tenant B), subsequent requests or cached queries for Tenant A are rejected and no stale Tenant A data remains visible.