Skip to content

Testing plan · Multi-tenant applications

Security testing for multi-tenant applications

A tenant-isolation test plan for records, search, exports, files and background jobs, with two controlled tenants and positive and negative evidence.

By BugSnaps · Updated

Start an authorized assessment View an example report

How do you test whether tenants are isolated?

Create controlled tenants with distinct records, then compare authorized access with requests from an identity belonging to another tenant. Include list views, files, search, exports and asynchronous jobs. A server's status code alone does not establish isolation; inspect the returned data and any state change.

Tenant identity can travel through a hostname, path, header, token or server-side membership lookup. Record which mechanism is authoritative for each operation. The aim is to check that every path into a customer resource enforces the same boundary, including paths the dashboard never renders.

Scope

Define the assets, actors and boundaries.

Use this plan to agree an assessment scope. The exact checks depend on your application, authorization and available test access.

Assets, test roles and priorities for multi-tenant applications
Asset or journeyTest contextsPriority
Individual records and collection APIsSame-role users in tenant A and tenant BCompare direct lookups, lists and search results.
Files, exports and share linksOwner, member and user in another tenantCheck data reached outside the main dashboard.
Jobs, integrations and administrationTenant administrator and platform operatorReview tenant context in privileged and delayed work.

Before the assessment

Prepare representative access and a clear scope.

  • Seed two tenants with unique harmless markers and document valid ownership.
  • Prepare both same-role and different-role accounts; separate platform support from tenant administration.
  • Specify whether cross-tenant sharing is ever valid and how such permission is granted and revoked.

Only test systems you own or have explicit permission to assess. Agree target boundaries, data handling and stop conditions before active testing.

Workflow

Move from a baseline to verified repairs.

  1. Step 1

    Map tenant identifiers

    List where the client supplies organization IDs and how the server derives membership. Include resource identifiers nested in request bodies and export jobs.

  2. Step 2

    Assess supported access checks

    Provide the authorized account contexts needed for an automated baseline. Review whether the report exercised both identities and which tenant-dependent paths remained unchecked.

  3. Step 3

    Compare owned and foreign resources

    Use controlled records to verify allowed and forbidden reads or writes. Manually inspect list filters, caches, file URLs and worker outputs that a direct resource check might miss.

  4. Step 4

    Retest the enforcement layer

    Confirm the foreign-tenant request no longer returns or changes the record while the owner's request still works. Add coverage to all routes using the affected data access layer.

Report evidence

Keep enough detail to verify and repair the issue.

Use controlled records, remove secrets and keep the result tied to the permission or workflow that failed.

  • The identity-to-tenant mapping and harmless markers that identify each test record.
  • Paired owner and foreign-tenant requests, redacted responses and observed state effects.
  • The tested access paths, missed routes and retest of the shared enforcement layer.

Use the evidence in the release decision

Treat a confirmed read or write across a prohibited tenant boundary as a specific data access defect. Preserve legitimate sharing controls in the fix, and record untested worker or storage paths separately.

Coverage and limits

Know what automation establishes and what needs a reviewer.

Automated baseline

Supported access-control checks can reveal evidence of cross-account behavior when valid contexts and resources are available. They cannot prove every tenant filter, cache key or background job is correctly implemented.

Review MyPentest's scope

Human review

Review tenant context propagation, customer-managed sharing, support impersonation and asynchronous work manually. Source and architecture review can identify paths that are difficult to reach from the external application.

Discuss the assessment scope

Common questions

Questions about testing multi-tenant applications.

Does using UUIDs provide tenant isolation?

No. An identifier's unpredictability does not replace the server's check that the requesting identity is allowed to access the particular resource.

Is checking individual record endpoints enough?

No. Search, collection responses, exports, files, caches and background jobs may use different access paths, so the test scope should include them where they exist.

How do we avoid touching another customer's data?

Create two test tenants you control and use synthetic records. Demonstrate the boundary failure with those records rather than retrieving data from a real customer.

References for this testing plan

These primary references inform the testing approach. They are not endorsements of BugSnaps or claims that a product implements every test in a standard.