To test tenant isolation, create two tenants with similar data, authenticate as tenant A, and try to reach tenant B's records through every path the product has: direct IDs, lists, search, exports, jobs and caches. Every attempt should return not found or forbidden, and never data.
Set up two tenants, not one
Most suites create a single test tenant. That cannot find isolation bugs, because there is nobody else to leak to.
Create tenants A and B with the same shape of data, and with deliberately overlapping values such as the same project name and the same user email domain. Overlap exposes bugs where a lookup uses a name instead of an id plus a tenant.
The checklist
- Fetch a B record by its id while signed in as A.
- Update and delete a B record by id as A.
- List endpoints return only A rows, even with page size set high.
- Search results contain no B rows for terms that match both.
- Sorting and filtering parameters cannot reference another tenant's field values.
- Export and report downloads contain only A data.
- Files in object storage cannot be fetched with a B path, including through pre-signed links created by A.
- Background jobs started by A cannot act on B ids supplied in the payload.
- Cache keys include the tenant, so A never receives a cached B response.
- Webhooks and notifications go to A's configured destinations only.
Make failure obvious
Assert on the response body, not only the status code. A 200 with an empty list is good. A 200 with B's row is the bug. Also check that error messages do not confirm that the B id exists, since a 403 versus a 404 can reveal that.
Generate the tests from your route list
Write a helper that walks your route table and, for every route with an id parameter, replays it with a foreign id. Fail the build if a new route is not covered or explicitly exempted. That keeps the checklist from decaying as the product grows.
What tests cannot prove
Tests find the paths you thought of. Pair them with a design rule that enforces the tenant filter in one place, such as a base query that always adds it, so that a forgotten filter is a code review finding and not a runtime surprise.
Try it yourself
The API security scan demo shows what an automated scan reports on endpoints. Look at how it reports authorization problems, then compare that with what your own two tenant tests would catch.
Click through it at your own pace, or open it full screen.
Quick check
Is one extra test tenant enough?
Two is the minimum. Add a third if you have parent and child organizations, so you can test sibling access as well.
Safeguard can run API security scans as part of its scanning, and you can start with a free scan at https://gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
