SaaS Security Audit Tenant Isolation Audit

Focused SaaS Security Audit

SaaS Tenant Isolation Audit

Test whether users, roles, tenants, and object IDs stay inside the correct SaaS boundary.

Your API can authenticate the user, return 200 OK, and still expose another customer's data. We replay real API requests, mutate tenant context, and compare responses to prove whether the boundary holds. Focused subservice under the broader SaaS Security Audit for teams that need tenant boundary testing on live API behavior.

Review tenant isolation risk

Problem

The bug looks normal until the data is wrong

Logs may show an authenticated request. Monitoring may show a healthy API. The failure is authorization, not availability.

Valid token, wrong object

The request authenticates, but object lookup skips tenant ownership and returns data from a different boundary.

Correct role, wrong tenant

RBAC looks right on paper, yet the live response comes from a tenant the caller should not reach.

Mixed tenant list responses

List and search endpoints quietly blend records from multiple tenants because the filter is missing or incomplete.

Admin scope bleeding across orgs

Support and admin actions cross boundaries when the code treats elevated access as global access.

Background jobs without tenant context

Async flows, exports, and workers lose the tenant identifier and start reading or writing outside the allowed boundary.

What We Test

What the tenant isolation audit checks

We test the boundary where tenant, role, object, and organization context intersect.

Object access boundaries

We verify whether IDs, slugs, and foreign keys are checked against the current tenant and owner.

Tenant scoped queries

We test whether API reads and writes preserve the tenant filter through the full request path.

RBAC and role boundaries

We check whether role changes actually change access, or whether the query still leaks data.

Organization switching

We replay the same request across tenants and accounts to catch boundary drift after switching context.

List endpoint filtering

We inspect pagination, search, counts, exports, and aggregates for cross-tenant bleed.

IDOR and BOLA paths

We mutate object IDs and observe whether the endpoint still returns 200 OK with the wrong payload.

Admin and support roles

We test elevated users separately because support tooling often becomes a global data surface.

Tenant context propagation

We follow tenant identity into middleware, services, background jobs, and async processing.

Evidence for suspicious access

We document the request and response pair that proves the boundary failed in practice.

Remediation priority

We call out which paths are highest risk so engineering can fix the real leak first.

Failure Patterns

What counts as a tenant isolation failure?

Tenant isolation failure is not only one user opening another tenant's record. It also includes mixed lists, boundary drift, async leaks, and response reuse across customers.

Replay another tenant's object ID

The request changes only the object identifier, yet the API still returns 200 OK with data from a different tenant.

Mixed tenant list responses

List, search, or aggregate endpoints return records from more than one customer boundary.

Valid role, wrong tenant object

The role is valid, but the returned object belongs to a tenant the caller should not reach.

Admin and support cross boundaries

Elevated access is treated like global access, so support paths can reach the wrong customer records.

Background jobs lose tenant context

Exports, workers, and async handlers drop tenant state and start reading or writing outside the allowed scope.

Wrong-tenant rows in exports or reports

A customer-facing export or report includes data that belongs to another tenant.

Cache keys reuse another tenant's response

A cached response is served across tenants because the key or invalidation path missed tenant context.

Audit logs cannot prove the tenant boundary

The trail exists, but it does not clearly show which tenant was accessed or whether the request stayed in scope.

How It Works

Real API behavior, not static assumptions

We replay real API requests, mutate tenant context, compare responses, and record evidence in a way engineering can use.

Map tenant-sensitive endpoints

We identify the request paths, object lookups, and tenant switches most likely to expose wrong data.

Capture baseline requests

We replay normal traffic so we have a known-good response to compare against mutated requests.

Mutate tenant context

We change actor, tenant, role, and object identifiers to stress the live authorization boundary.

Compare status and body

We compare status codes, response bodies, and field-level differences rather than trusting 200 OK.

Document evidence and priority

We package the proof, severity, and remediation order so the team can act quickly.

Proof

What evidence proves tenant isolation failed?

Tenant isolation issues need request-level evidence, not vague claims. We show exactly which actor, tenant, object, and response created the boundary break.

Baseline request The known-good request that establishes the normal tenant boundary.
Mutated request The replay that changes the object, tenant, role, or actor.
Actor and tenant used The exact identity context that produced the result.
Expected result What should have happened if the boundary check worked.
Actual result The response the API actually returned under mutation.
Response diff The field-level change that shows the wrong tenant data.
Affected object or record The resource that crossed the boundary or leaked in the response.
Risk explanation Why the finding matters for customer trust, enterprise review, or compliance.
Retest path after fix The exact replay needed to confirm the boundary now holds after remediation.

For SaaS teams

Who this audit is for

This is for SaaS teams that need proof their tenant boundary holds under real request behavior.

Multi-tenant SaaS products

APIs with organization or workspace switching

Products using RBAC or custom roles

Teams preparing for enterprise customers

Platforms exposing object IDs in routes or requests

Teams unsure whether tenant filters are enforced everywhere

Deliverables

What you get

The output is commercial, reproducible, and specific enough to hand to engineering without translation.

Tenant isolation findings

Clear notes on where the boundary fails and which requests returned the wrong tenant's data.

Affected endpoints

A short list of the APIs, objects, and flows that need correction first.

Request and response evidence

Baseline and mutated request pairs, response diffs, and enough detail to replay the issue.

Severity and business risk

Why the leak matters for customers, enterprise review, compliance, and incident exposure.

Reproduction notes

Step-by-step notes that engineering can use during fix work and retesting.

Suggested fix direction

Practical guidance on query scoping, authorization checks, tenant context, and async flows.

Priority list for engineering

A fix order that helps the team close the highest-risk leak paths first.

Optional remediation support

If the findings need implementation work, we can help shape remediation without turning the engagement into a development retainer.

Pricing

Simple pricing for a focused tenant boundary review

Start with the audit if you need proof on the boundary itself. Add the remediation plan when the findings point to architecture or implementation work.

Tenant Isolation Audit Starting point

Focused review of tenant boundary risks in a SaaS API

Check whether users, roles, and tenants can access data outside their allowed boundary.

Best when you need proof fast on a specific product surface before a customer or enterprise review.

Project Investment

From €750

Includes endpoint review, controlled request mutation, tenant and object access checks, evidence report, and remediation priorities.

What's Included

Endpoint review
Controlled request mutation
Tenant and object access checks

Evidence report
Remediation priorities

Review tenant isolation risk

Tenant Isolation Audit + Remediation Plan

For teams that need fix direction after the audit

Everything in the focused audit plus architecture recommendations and developer handoff.

Best when the findings point to query scoping, tenant propagation, or broader implementation work.

Project Investment

From €1,500

Includes everything in the audit, plus fix planning, architecture recommendations, and developer handoff.

What's Included

Everything in the audit
Fix planning
Architecture recommendations

Developer handoff
Optional retest support

Review and plan remediation

Choose the right audit

When this is better than a cross-tenant data leak audit

Use the tenant isolation audit when the main question is whether users, roles, tenants, and objects stay inside the correct boundary across API requests.

If the scope also includes RBAC, caches, background jobs, exports, and support workflows, use the broader Multi Tenant Security Audit.

Use Tenant Isolation Audit

Choose this when the core question is object replay, tenant-scoped access, and whether the API keeps every request inside the correct boundary.

Use Cross Tenant Data Leak Audit

Use Cross Tenant Data Leak Audit when customer data is already leaking through reports, exports, cached responses, background jobs, analytics, or admin paths.

Use Multi Tenant Security Audit

Use Multi Tenant Security Audit when the product needs broader review across API authorization, RBAC, shared schemas, cache, jobs, exports, and support workflows.

Use SaaS API Authorization Audit

Use SaaS API Authorization Audit when the focus is specifically request-level authorization across actors, roles, and objects.

If the boundary question is broader than one page, start from the SaaS Security Audit hub and route into the narrower audit that matches the risk.

Broader audit

Part of a broader SaaS Security Audit

Tenant isolation is one of the highest-risk areas in a SaaS platform. See the full SaaS Security Audit when you also need BOLA testing, API authorization review, audit logging review, and broader runtime security validation.

Need the full service instead?

Runtime authorization, BOLA, audit logging, and implementation-level security review sit in the broader audit scope.

View SaaS Security Audit

Related resources

What is tenant isolation in SaaS?

Tenant isolation means each customer can only access the data, objects, and actions that belong to their own tenant boundary.

What is a cross-tenant data leak?

It is a failure where one tenant can read or act on another tenant's data, often through an authenticated API request that returns the wrong payload.

How is tenant isolation testing different from normal API testing?

Normal API testing checks that endpoints work. Tenant isolation testing checks whether the same endpoint still blocks the wrong tenant, role, or object.

Can a valid user token still expose another tenant's data?

Yes. Authentication can be correct while authorization fails, which is why a valid token does not prove the response is safe.

Is this the same as BOLA testing?

BOLA is one of the main ways tenant isolation fails. Tenant isolation testing is broader because it also covers tenant-scoped lists, roles, organization switching, and async flows.

Do you need source code access?

No. We can start from live request behavior. Source access helps us go deeper into query logic, background jobs, and fix direction.

What do we receive after the audit?

You receive evidence-backed findings, affected endpoints, reproduction notes, severity, and suggested fix direction.

Can you help fix the findings?

Yes. If the audit shows structural risk, we can move into remediation planning or implementation support after the audit.

Final CTA

Find tenant leaks before customers do

If your SaaS API handles multiple tenants, roles, or organizations, test the boundary before a customer, auditor, or enterprise buyer finds the gap.

Review tenant isolation risk