SaaS tenant isolation means that a customer can access only the records and operations their organisation is entitled to use. A tenant selector in the interface is not enough. The boundary needs to hold when requests, background jobs, caches and file downloads reach the underlying systems.
Test tenant isolation using separate organisations, ordinary user roles and deliberate attempts to cross their boundaries. Verify reads, writes, files, cached responses and background work against the same access rules. Request evidence from the enforced backend boundary before onboarding customers with sensitive or commercially important records.
Imagine a customer portal where each organisation sees its own purchase orders. The list screen looks correct, but a downloaded export contains another organisation’s rows. That is an isolation failure even if login and the ordinary page route work as intended.
This guide helps an owner scope verification and remediation. It is not a claim that one database layout guarantees security or that a checklist replaces a complete application assessment.
Define SaaS tenant isolation before choosing storage
Identify what a tenant means in the product. It may be a customer organisation, a legal entity or a workspace. Record how users join, leave and switch between tenants, and which support roles can act across them. Ambiguity in those rules becomes ambiguity in the tests.
The OWASP multi-tenant security guidance describes isolation across database, cache, storage and compute boundaries. It also distinguishes a client-supplied tenant selector from server-verified authority. Use that distinction when assessing the product’s actual request path.
Define data ownership explicitly. A shared product catalogue may be intentionally visible to several customers, while order notes are tenant-owned. Tests need to know the difference so they identify leaks without classifying deliberate shared information as a defect.
Map the administrative exception. If support staff can inspect a customer’s records, explain who grants that access, how it is scoped and how its use is recorded. A powerful support path should be tested as an intentional capability rather than hidden outside the normal tenant model.
Follow tenant context through the request
Begin with an authenticated user and verify their current membership or service authority. Follow the selected tenant into business logic and data access. Check that changing a header, route value or request body cannot substitute another organisation’s authority.
Random-looking identifiers can make guessing harder, but they do not establish permission. OWASP’s authorisation guidance recommends checking access on every request. Test an identifier obtained legitimately from another tenant rather than relying on whether a tester can guess it.
| Boundary | Illustrative attempted change | Accepted result |
|---|---|---|
| Record lookup | Request another tenant’s known order identifier | Refusal without record disclosure |
| Update | Submit another tenant’s identifier in a valid payload | No unauthorised modification |
| Tenant switch | Select an organisation without membership | Server rejects the requested scope |
| Bulk endpoint | Include mixed-tenant identifiers | Defined rejection without partial leakage |
| Support action | Use an ordinary role on an elevated route | Refusal and useful investigation evidence |
Repeat this reasoning for search, exports and alternate APIs. The first correct detail screen does not prove that a bulk report, mobile endpoint or old compatibility route enforces the same boundary.
Compare database approaches by their real controls
Separate databases, schemas and shared tables create different operational trade-offs. None removes the need to verify credentials, roles, queries and administrative paths. The proposal should identify where the boundary is enforced and what would happen if application code omits a filter.
| Approach | Boundary to inspect | Operational work to include |
|---|---|---|
| Separate databases | Connection and credential authority | Provisioning, migrations and backup separation |
| Separate schemas | Database roles and namespace selection | Grants, migration discipline and administrative access |
| Shared tables | Tenant ownership and enforced access policies | Query coverage, request roles and negative tests |
| Hybrid | The documented rule for each data class | Clear routing and consistent incident investigation |
Avoid treating a migration to separate databases as the default fix for every defect. A bounded authorisation bug may have a targeted repair. Equally, adding a filter in one controller is insufficient when exports, jobs and support tools still use unrestricted access.
Test the role that production requests actually use
PostgreSQL’s row-security documentation explains important exceptions, including privileged roles and table ownership. Where the product relies on row policies, verify them using the actual constrained request role. A test executed as a database administrator does not represent the ordinary application’s boundary.
Include deployment and migration accounts in the inventory. They may legitimately require broader access, but should not become the routine identity for customer requests. Document how the runtime obtains its intended authority and how that arrangement is checked after deployment.
Check caches, files and derived outputs
Inspect cache keys and the scope of cached results. A cache entry created for one organisation must not become an answer for another because both requests share a convenient route or filter. Test the second tenant after the first has populated the cache.
Files need their own acceptance evidence. Verify upload ownership, preview access, downloads and generated reports. A page can refuse access correctly while an attachment URL remains available through an unrelated route. Include stale and previously issued links in the agreed test scope.
Check derived data such as search indexes, recommendations and analytics exports. Establish whether the system enforces tenant restrictions when retrieving that data, not just when inserting it. Information can cross a boundary through a summary even when the source record endpoint is protected.
Use controlled fixtures belonging to distinct organisations. Give each enough recognisable content to identify contamination without copying real customer documents into the assessment. This makes an unexpected cache hit or mixed export easier to diagnose.
Exercise background jobs and membership changes
Background work should carry verified tenant context through the queue and into the operation. Check what happens if a job is delayed, retried or picked up by a different worker. A valid tenant scope in the web request is not proof that the later job preserves it.
Test changes in membership. A user removed from an organisation should not retain ordinary access through a cached session, saved export or pending operation contrary to the agreed policy. Define the intended behaviour for work already accepted before revocation.
Support impersonation and tenant deletion also deserve deliberate coverage. Explain how operators leave an elevated session and how residual files, jobs and references are handled. The correct deletion policy depends on the product’s retention obligations; the assessment should verify the chosen policy rather than invent one.
Our software project takeover guide is relevant when the current team cannot explain those paths. Recovering ownership of deployment, data access and operational documentation can be part of making the boundary maintainable.
Specify a useful verification report
Request findings that show the actor, tenant, operation and observed effect. Include the relevant request and destination evidence with sensitive values appropriately controlled. A finding labelled access control without a reproducible path is difficult to repair and difficult to retest.
OWASP ASVS can support the broader application-security requirements. Keep the tenant-specific acceptance matrix alongside that work so the reviewer can see which organisations, roles and resource types were exercised.
Separate confirmed defects from untested paths. If the assessor could not inspect a private storage service or an administrative export, say so. An honest scope limitation is more useful than an unsupported conclusion that all tenant data is isolated.
After remediation, repeat the original failing case and nearby legitimate cases. A repair that blocks all downloads may stop the leak but break the product. Acceptance needs both the refusal of unauthorised access and the continuation of permitted customer work.
Budget for the product’s actual boundary
Scope the assessment using resource types, roles and operating paths rather than page count alone. Include external files, caches, background jobs and support access when they can expose tenant-owned information. A small portal may have a wider boundary than its interface suggests.
| Work package | Deliverable | Assumption to clarify |
|---|---|---|
| Boundary mapping | Tenant and role model | Availability of architecture knowledge |
| Verification | Positive and negative access evidence | Controlled accounts and environments |
| Remediation | Corrected enforcement and regression checks | Whether structural changes are needed |
| Handover | Repeatable tests and known exclusions | Ownership after onboarding |
Request GBP proposals with assessment and remediation distinguished. Avoid accepting a universal assurance based only on a login test or an automated scan. The valuable deliverable is evidence about the access boundaries your customers will depend on.
Our application security service provides a starting point for that scope. Send us the product’s tenant model and onboarding decision to discuss verification, targeted repairs and the evidence needed before opening the next customer account.
Frequently Asked Questions
What is SaaS tenant isolation? It is the enforced separation of customer organisations’ data and permitted operations. The boundary needs to hold across application requests, storage, caches, files and background work, including administrative exceptions defined by the product.
Do separate databases guarantee isolation? No. Credentials, routing, support tools, exports and backups can still cross boundaries. Separate databases can form part of the design, but the actual access paths need testing.
Are random record identifiers enough? No. They can reduce easy enumeration but are not permission checks. Test access using a real identifier from a different controlled tenant and confirm that the server refuses it.
Should we test permitted access as well as refusals? Yes. A remediation that denies every request can conceal a broken product. Verify that ordinary users retain their intended operations while cross-tenant attempts are rejected.
Why do caches need separate tests? They can return data without repeating the original data-access path. Populate a cache under one tenant and inspect the result under another. Confirm that the cache’s scope preserves the intended authority rather than merely sharing a convenient key.
How should support access work? Define who may obtain it, what scope it grants, how long it lasts and how actions are recorded. Test entry, use and exit from that elevated context. The design should make the exception explicit and reviewable.
What if we use row-level security? Test it with the application’s actual request role and include operations that bypass ordinary controllers. Privileged database roles and other access paths can have different behaviour. Row policies are a control to verify, not a reason to omit the assessment.
What should a supplier receive before quoting? A description of tenants and roles, resource types, external storage and background operations. Identify the environments and controlled accounts available for testing, along with the decision the assessment must support.