Tenant switching security: test workspace context after login

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

Tenant switching security testing evaluates whether requests, background jobs, and cached views follow the workspace a user is authorized to access. A visible workspace selector does not establish that every downstream service uses the same trusted tenant context.

OWASP discusses tenant isolation as a security boundary across application components. OWASP Multi Tenant Security Cheat Sheet provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

State the membership and switching rules

Define how a person gains access to a tenant, how the current tenant is selected, and whether membership changes invalidate active work. Include users with multiple memberships because their legitimate switching path differs from a single-tenant account. Inventory caches, export workers, search services, and websocket subscriptions that carry tenant context. Ask which component is authoritative for membership. A tenant identifier supplied by a client may be useful input, but the assessment must establish how the server connects it to current permissions.

Exercise a two-workspace timeline

Create owned workspaces with visibly different synthetic records. Give one test account access to both and a second account access to only the first. Perform ordinary switching and start a harmless asynchronous export. Under owner supervision, remove one membership while that work is pending, then evaluate the documented revocation rule. The expected result depends on the agreed policy, so decide it before the test. Do not use a live customer workspace, production personal records, or external invitations as fixtures.

Observe hidden tenant carriers

Inspect the approved traces for the web request, background job, search query, and delivered artifact. Record which identity and tenant each component used, without exposing secrets in the report. A front-end title can show the new workspace while an older subscription continues to deliver data from the previous context. Conversely, a job may legitimately complete under a documented snapshot rule. The evidence should show whether behavior matches the intended contract, rather than declare every stale process a breach.

Turn the result into a regression contract

Document switch, removal, and re-entry outcomes with timestamps and role context. Retest both a denied account and a legitimate dual-member account after changes. Make sure performance caches and asynchronous systems are included where they were involved in the finding. This sample cannot establish isolation for every tenant or deployment region. Identify untested integrations and storage layers so a future assessment can extend coverage. For procurement, ask a provider to explain its test identities and context-tracing method before comparing vulnerability counts.

A useful assessment artifact

A context timeline is a useful deliverable: membership creation, workspace selection, job start, membership removal, and artifact delivery. It exposes disagreements between services without requiring raw customer content or a large collection of nearly identical request traces.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.