A Multi-Tenant Isolation Acceptance Matrix for Your Own Staging
In your own authorized staging environment, create two synthetic tenants and write the expected access decision for each selected operation. Then check that the server enforces that decision across the API, files, exports and background work in your scope.
This is an original CodeMyTown acceptance worksheet for a developer and product owner. We sell source code and templates, so treat it as vendor-authored planning guidance, not independent certification. Passing selected checks does not prove complete isolation, compliance or overall application security.
Establish permission and a safe test boundary
Use only an installation you own or are explicitly authorized to test. Create synthetic tenants, users and records that you control. Do not perform cross-account probing in a seller's public demo, access real customer records or run disruptive tests against shared infrastructure. Agree the operations, environment, responsible developer and stop conditions before beginning.
Keep payment, messaging and other external services sandboxed. The worksheet concerns access decisions and observable side effects, not load generation or attempts to exhaust a service. If an expected denial returns data outside your synthetic test scope, stop, preserve the minimum sanitized evidence and notify the authorized owner through the agreed route.
Define what each account is allowed to do
Create tenant A and tenant B with distinct synthetic markers, such as SAMPLE-A and SAMPLE-B. Give each an ordinary member and, if your product has them, a tenant administrator. List any platform-operator role separately. An operator may intentionally have wider access, but that permission needs a stated purpose and appropriate logging rather than being confused with ordinary membership.
OWASP's authorization guidance recommends default denial and permission checks on every request. Use that principle to write the expected decision before running the case. A hidden navigation item is an interface choice; it does not establish what the server permits.
Build the acceptance matrix
| Controlled case | Expected result to agree | Evidence beyond the status code |
|---|---|---|
| A member reads A's sample record | Allowed if that role is entitled to read it. | Response contains the intended sample marker and allowed fields. |
| B member requests A's sample record | Denied under the application's chosen response contract. | No record fields, attachment link or other sensitive content escapes. |
| B member requests a change to A's sample record | Denied with no unauthorized change. | A's record and any related job or notification remain unchanged. |
| A member requests an administrator-only action | Denied unless the access model explicitly grants it. | No privileged result is created through a direct request. |
Run allowed cases as well as denied ones. If every request fails because the environment is broken, you have not established a useful authorization boundary. Agree whether a forbidden request should return a forbidden or not-found response; the essential acceptance condition is that it does not expose or modify unauthorized data.
Follow the data beyond the main page
For each chosen record, identify the other paths that expose it: search results, exports, attachments, notifications and background jobs. Use the normal authorized workflow to create your synthetic export or file, then evaluate access under the other controlled account. Avoid guessing identifiers belonging to anyone outside the exercise.
The OWASP multi-tenant guidance discusses tenant context across storage, caches and background work. Apply that scope to a small set of original acceptance cases: repeated requests from alternating sample tenants should not return the other tenant's cached result, and an export job should use the tenant context intended when it was created. Have the responsible developer inspect the relevant job and storage rules as well as the visible output.
A successful read denial does not establish write protection. Check the permitted synthetic update case separately, then examine the stored result using the authorized owning account. If a request queues work, verify that no later job bypasses the decision that the web request appeared to enforce.
Treat identity and tenant context as server decisions
Record how the application determines the current user, workspace membership and requested operation. Values sent by a browser can describe a requested context; they are not proof that the requester belongs to that context. A developer should explain where the trusted membership and ownership checks occur.
You do not need a particular database tenancy architecture or a custom subdomain to complete this worksheet. Separate databases, separate schemas and shared tables have different operational implications. Evaluate the actual access model and its enforcement rather than declaring an architecture safe because it uses a fashionable identifier or URL pattern.
Record failures and retest the affected boundary
For each case, keep the release identifier, test role, synthetic record, expected decision, observed result and responsible owner. Store only sanitized request information; exclude session tokens and private credentials. Classify a result as passed, failed or not exercised. A screenshot of an error page is weaker evidence than a record that also confirms no unauthorized data or side effect appeared.
If a case fails, pause release decisions that rely on that boundary. The developer should fix the enforcement point and repeat the failed case plus relevant neighboring cases. For example, a file-download fix needs checks for the owning account, the other tenant and the unauthenticated state. The extent of further review depends on the application and the failure, not on a universal checklist score.
Make the chosen cases part of the project's maintained acceptance record so later changes can be checked against the same expectations. Use the pilot worksheet to decide who accepts the result and the API contract worksheet to define client behavior around denied requests. StockNova itself is a frontend template and supplies no production tenant isolation; the checks here apply to a backend that you separately build or evaluate.
Frequently asked questions
Where should I run tenant-isolation acceptance checks?
Run them only in an environment you own or are explicitly authorized to test, using synthetic tenants, users and records. Do not probe real customers or other accounts in a seller’s public demo.
Does a forbidden status code prove isolation?
No. Also confirm that no unauthorized fields, links, stored changes or later side effects appear, and run the corresponding allowed case to ensure the environment works.
Do separate tenant subdomains prove data isolation?
No. A URL pattern does not establish server-side permissions. Evaluate how membership, ownership and each requested operation are enforced in the actual application.
Does passing this matrix certify a multi-tenant application?
No. It records selected observations for one version and environment. It is not a complete security assessment or proof of compliance, and untested surfaces remain outside the result.
Get a quote or a guided demo
Tell us your use case and we'll send pricing, a live demo walkthrough and licensing options for CodeMyTown source-code and frontend-template scopes. Usually a reply within one business day (IST).