A multi-tenant penetration test should validate isolation across every place tenant context is stored, transformed or consumed—not only the public API. Database access, cache keys, background jobs, exports, object storage, search indexes and administrative tools can each reintroduce cross-tenant access after an endpoint appears properly authorized.

Model tenant context as security data

Document where tenant identity originates, how it is bound to the authenticated actor and how it travels through the system. If a client supplies a tenant ID, identify the server-side membership check. If the gateway adds a claim, determine whether downstream services verify the issuer, audience and relationship rather than merely trusting a header.

Trace transformations into database predicates, cache namespaces, queue messages, storage prefixes and export jobs. A single dropped or defaulted tenant field can turn a local authorization weakness into platform-wide disclosure.

Create a controlled tenant test matrix

  • Two ordinary users in different tenants.
  • Tenant administrators with similar roles but separate ownership.
  • Shared user or invited collaborator where supported.
  • Suspended, removed and recently transferred memberships.
  • Objects with predictable and opaque identifiers.
  • A platform-support role tested only under explicit authorization.

Seed distinguishable canary records and files. Record authoritative ownership before each test so a response cache, stale index or legitimate collaboration is not mistaken for a bypass.

Test database access beyond identifier swapping

Vary object IDs in reads, writes, bulk operations, filters, nested resources and relationship updates. Check whether tenant predicates are applied in joins, stored procedures, ORM scopes, raw queries and administrative search. Test both a known foreign identifier and an enumeration attempt that should reveal nothing.

  • Parent is authorized but child belongs to another tenant.
  • Bulk list filters accept an alternate tenant value.
  • Update or delete uses object ID without tenant predicate.
  • Uniqueness checks reveal a foreign customer record.
  • Soft-deleted or archived data bypasses normal scope.

The strongest control binds actor, tenant and object in the same authoritative query or policy decision. A prior existence check followed by an unscoped mutation can still race or drift.

Challenge cache namespaces and invalidation

Inspect how cache keys incorporate tenant, user, role, locale and permission-sensitive variants. Repeat the same URL or query under alternating tenants; vary headers, hostnames and tokens; and test after role removal. Confirm that invalidation removes the correct tenant entry without exposing another tenant’s cached representation.

  • Shared key omits tenant or permission dimension.
  • Negative cache reveals another tenant’s object existence.
  • Edge cache ignores Authorization or tenant-specific host.
  • Application cache stores a privileged response for ordinary users.

Follow tenant context into background jobs

A queue consumer often runs with broad service privilege. Test whether the producer places an authoritative tenant reference in the message, whether the consumer revalidates object ownership, and whether retries preserve the original authorization decision too long. Include scheduled jobs, imports, notifications, billing and cleanup tasks.

  1. Create an authorized job in tenant A and capture its identifiers.
  2. Attempt to substitute tenant B object, destination or job reference.
  3. Change or revoke the initiating user before execution.
  4. Trigger retry, duplicate or out-of-order delivery where safe.
  5. Inspect final state, logs, files and messages in both tenants.

Do not infer safety from a rejected enqueue request. The consumer is the final authority for the side effect and must not trust editable message metadata blindly.

Test exports as delayed authorization decisions

Exports combine broad queries, file creation and long-lived download links. Verify the export query is tenant-scoped, the requester remains authorized at retrieval where required, generated files use unguessable references, and signed URLs cannot be rebound or reused outside the intended lifetime.

  • Filters or report templates carry a foreign tenant value.
  • Export status endpoint reveals another job.
  • Download URL remains valid after access revocation.
  • CSV, PDF or archive contains hidden cross-tenant rows.
  • Notification sends the export to an unverified address.

Verify object-storage isolation

Map upload, processing, preview and download paths. Test whether bucket keys or metadata are derived from client-controlled tenant IDs, whether signed operations restrict key and content type, and whether image or document processors can fetch a foreign object. Review list permissions and error differences that enable enumeration.

Include search, analytics and logs

Search indexes and analytics stores may denormalize tenant data and lag revocation. Query by global identifiers, facets, suggestions and exports. Check whether support logs, traces or error reports expose payloads across tenants to roles that should see only their own environment.

Test shared administrative surfaces

Support consoles, migration tools and impersonation features sit outside customer APIs but can defeat isolation. Verify explicit tenant selection, reason capture, step-up authentication, least privilege and auditability. Ensure a copied object URL or stale browser tab cannot silently switch the operator into a different tenant context.

Measure isolation failures by blast radius

Report whether the flaw allows read, write, execution, enumeration or availability impact; whether identifiers must be known; which components share the failed control; and how many tenants could be affected. Avoid describing a platform-wide architecture defect as one endpoint issue.

Fix at the enforcement layer

Prefer tenant-aware repositories, policy libraries, message schemas, cache-key builders and storage brokers over repeated ad hoc checks. Add negative cross-tenant tests to each shared component. Where physical separation is promised, verify credentials and infrastructure policy enforce it rather than relying on naming conventions.

Retest every consumer of the shared pattern

After remediation, repeat the proof and sample other endpoints, workers, exports and storage operations using the same library or data path. Confirm tenant context survives retries, revocation, cache hits and administrative workflows, and that legitimate collaboration still works.

Use the OWASP Web Security Testing Guide for authorization testing foundations, then extend the plan across caches, queues, files and control planes where tenant isolation failures frequently hide.

The architecture decision

Tenant isolation is an end-to-end property. Scope the assessment around tenant-context propagation and final side effects, use paired tenants with canary data, and require evidence from databases, caches, workers, exports, object storage and administrative paths—not only HTTP status codes.

Ask WIMD to assess multi-tenant isolation end to end across the shared components that carry the largest customer blast radius.