A multi-customer SaaS shares some infrastructure while keeping each customer's data separate. That separation needs evidence across the product, not only a customer identifier on the main database table. Ask the agency to demonstrate forbidden access as well as successful use.
Related service: Custom software development- 01Create two realistic customer accounts.
- 02List customer-scoped data and actions.
- 03Exercise normal and direct access paths.
- 04Test background work and downloads.
- 05Keep regression evidence with each release.
SECTION 01
Name what belongs to a customer account
A customer, sometimes called a tenant, may contain several users and workspaces. Decide whether a person can join multiple customers and how they switch context. A shared consultant should not carry the first customer's permissions into the next merely because the same login is used.
OWASP's multi-tenant guidance covers more than database rows, including files and asynchronous work. PostgreSQL row security is one possible data-layer control, with important role and bypass behavior to understand. Neither choosing a database feature nor labeling the architecture multi-tenant establishes that the whole application is isolated. Ask where the boundary is enforced and which exceptions are intentional.
SECTION 02
Illustrative example: a report generated in the background
Imagine a customer requests a project export, then switches to another workspace before the file is ready. The job must retain the original authorized account context. The resulting download must remain accessible only under the appropriate membership. This is an illustrative test case, not a certification claim.
Now remove the requesting user's access before the download. Agree whether the job continues for the account owner, is cancelled or completes without granting the former user access. Test the file's direct link, not only the button that reveals it. A correct database query does not prevent a publicly reachable export file from leaking the same data.
SECTION 03
Choose complete checks over architectural labels
A first release can use a straightforward account model with limited roles. Separate databases may increase some isolation but also add operational work; shared storage can be appropriate with correctly enforced boundaries. The agency should explain the choice against actual risks and operating capacity, not speculative scale.
Request tests that change record identifiers, reuse saved links, search for another account's names and trigger concurrent exports. Include shared caches, scheduled jobs and administrative tools in the review. Keep a list of known exclusions and the evidence produced. These checks support acceptance of the agreed implementation; they are not a guarantee that the product has no security defects.
SECTION 04
Frequently asked questions
Does a unique customer ID prove isolation?
No. Every customer-scoped access path must enforce the boundary, including files, searches, exports and background tasks.
Must every customer have a separate database?
Not always. Compare the isolation and operational tradeoffs against the product's requirements, and test the chosen design rather than relying on its label.
Should tests use administrator accounts?
Use ordinary customer roles for isolation checks. An administrator's intentional broad access cannot demonstrate the restrictions applied to normal users.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Multi-tenant application securityOWASP Foundation
- Row security policiesPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy