Security and Privacy
Test tenant isolation before opening a shared platform
A shared platform needs evidence that one customer organization cannot receive another’s records through ordinary features or operational shortcuts. Test tenant context across queries, files, jobs, caches, and support access before widening access.
A tenant is a customer organization or another defined isolation unit within a shared service. Sharing infrastructure does not mean sharing customer access. Before opening a platform to more organizations, ask the team to demonstrate that tenant boundaries follow data through the whole workflow, including operations that customers never see directly.
Define the boundary before the test
OWASP recommends validating permissions on every request and discusses attribute-based access decisions for multi-tenant systems.[1] Begin with a written rule for tenant membership, shared resources, and cross-organization collaboration. A role such as administrator needs an explicit scope.
Recommend separating customer administrators from platform operators in the policy. Identify any legitimate sharing before writing negative tests. Without that definition, a successful cross-tenant action might be either a defect or an undocumented feature. Neither interpretation should depend on a developer’s memory.
Trace tenant context across shared services
Ask how the service establishes tenant context from verified identity and permitted membership. Then trace that context through data queries, file retrieval, search, cache lookups, background jobs, and exports. Treat each path as a separate acceptance surface.
OWASP warns that client-side access controls are insufficient and calls for server-side checks.[1] Do not accept a tenant selector or a hidden navigation item as the isolation mechanism. Recommend explicit checks when a job starts and when its output becomes available, especially if membership can change between those events.
Hypothetical example: a shared inventory service
In a hypothetical inventory platform, two retailers use the same product service. Each retailer has its own stock and reorder reports. Synthetic test data gives each retailer recognizable but non-sensitive records so reviewers can identify an incorrect result.
The team verifies ordinary reports, a delayed export, and a cached dashboard after an authorized user switches organizations. It also tests removal from an organization before a queued report finishes. These hypothetical cases define expected evidence, not a claim that the platform contains or eliminates a particular defect.
Isolation evidence to request
Use only approved accounts and synthetic tenants. Keep the test scope documented and do not test against unrelated customer data.
- Define tenant membership and every permitted sharing exception.
- Check reads, changes, files, search, and aggregated results.
- Include caches, queues, scheduled exports, and output download permissions.
- Test membership removal and organization switching during active work.
- Review scoped operator access and safe audit evidence for exceptions.
Recognize architectural tradeoffs
Shared tables, separate schemas, and separate databases create different operational costs and failure boundaries. No storage choice removes the need for authorization. Ask for an architecture-specific test plan and clear ownership of shared services. Isolation evidence should become a recurring release requirement when data paths change, not a one-time demonstration that only the first customer’s dashboard looks correct.
