Focused SaaS Security Audit

Cross Tenant Data Leak Audit

Test whether one tenant can access, receive, export, cache, or infer another tenant's data through real application behavior. We replay Tenant A requests under Tenant B, compare the returned records, and check whether the system still leaks across the boundary. When cross-tenant leakage risk spans APIs, roles, jobs, exports, caches, and privileged workflows, the broader [multi tenant security audit](/saas-security-audit/multi-tenant-security-audit/) is the better fit.

Request-level evidence Severity ratings Retest checklist From €750

Review cross-tenant leak risk

View broader security audit

Evidence Example

Proof that the same report becomes unsafe under tenant mismatch

A valid response for Tenant A does not prove the system is safe. We replay the report request under Tenant B and compare what comes back.

Valid tenant request

GET /api/reports/monthly

User A from Tenant A receives Tenant A report data and the expected response shape.

Tenant mismatch

GET /api/reports/monthly

Unsafe result

200 OK with Tenant A records, mixed tenant report rows, cached Tenant A response, or metadata from another customer

Risk: This is cross-tenant exposure because one customer can receive another customer's data through a real application path.

WHAT THIS PROVES

The tenant boundary failed under request replay. You receive the request pair, response evidence, severity rating, fix direction, and retest checklist.

DELIVERABLES

What you receive from the audit

The output is written for engineering and buyers who need clear proof, not generic findings language.

Evidence Package

Executive summary
Tenant boundary risk map
Affected endpoint list
Baseline and mutated request pairs
Cross-tenant evidence
Response diffs and side effects

Engineering Handoff

Severity ratings
Remediation guidance
Retest checklist
Audit log gaps if relevant
Optional architecture notes
Recommended next steps

Pricing

Pricing for focused and broader authorization audits

Start with a narrow workflow review or move into the broader audit when roles, tenants, exports, or support access make the boundary more complex.

Focused Cross-Tenant Leak Audit

For one tenant-sensitive workflow, report, export, or API area

A targeted review for one tenant-sensitive flow where leak risk has to be proven in live requests.

Best when one tenant-sensitive area is the highest-risk gap and you need fast proof on it.

PROJECT INVESTMENT

From €750

Includes 3 to 5 critical tenant flows, evidence-backed findings, and fix direction for the chosen surface.

What's included

3 to 5 critical tenant flows
Tenant mismatch testing
Read, list, or export checks

Evidence-backed findings
Reproduction notes
Remediation direction

Review cross-tenant leak risk

SaaS Data Exposure Audit Most relevant

For products with tenants, reports, analytics, exports, caching, jobs, or support access

The most relevant option when the product has enough multi-tenant complexity that one workflow review is not enough.

Use this when the architecture includes shared schemas, cache layers, jobs, and multiple leak-sensitive workflows.

PROJECT INVESTMENT

From €1,500

Most relevant for SaaS teams that need a broader data exposure review with practical risk classification.

What's included

Multiple tenant and user scenarios
API, list, export, cache, and job boundary checks
Baseline and mutated request evidence

Risk ranking and fix guidance
Retest checklist included

Review cross-tenant leak risk

Full SaaS Security Audit

For broader runtime security validation

A broader audit path when cross-tenant leakage is only one part of the risk picture and the system needs a wider review.

Best when cross-tenant leak testing, tenant isolation, API authorization, RBAC, audit logs, and general API risk all need to be reviewed together.

PROJECT INVESTMENT

From €3,000+

Use this when the issue spans more than one control area and the system needs a broader review.

What's included

Cross-tenant leak testing
Tenant isolation review
API authorization and RBAC review

Audit log review
Broader findings summary
Optional implementation support

View audit

TRIGGERS

Signs the audit is worth doing now

This is most useful when the product already serves multiple customers and the team needs proof that data does not leak across them.

COMMON TRIGGERS

A quick checklist for boundary risk

Multiple companies, workspaces, or organizations share the same product
Shared schema, shared infrastructure, or tenant context passes through code
Exports, reports, files, or analytics are tenant-scoped
Background jobs process customer data
Support or admin users can access customer accounts
Customers ask how tenant isolation is proven

BUYER PROOF

Request It Before Buyers Ask

Use this audit before a security review, enterprise sale, customer questionnaire, or tenant-sensitive release.

You get request-level evidence, risk ranking, fix guidance, and a retest checklist your team can use directly.

Request Audit Scope View Sample Report

PROBLEM

Cross-tenant leaks are dangerous and often quiet

A SaaS system can look healthy while still leaking across customers. The failure often hides in tenant filters, shared schemas, joins, cached responses, exports, reports, analytics, admin tools, background jobs, or logs that only show successful requests.

COMMON LEAK PATHS

Valid sessions can still receive the wrong tenant's records if the boundary is not enforced at read time.
Shared schemas depend on tenant filters that can drift in joins, search, exports, or alternate endpoints.
Cached responses and background jobs can carry the wrong tenant context even when the main API path looks correct.
Admin, support, and reporting workflows often touch customer data and can bypass the expected boundary if not tested directly.

WHY NORMAL CHECKS MISS IT

Normal Checks Do Not Replay Context

QA, logs, and infrastructure scans often confirm that a request succeeded. They do not prove the returned object, export, cache entry, or background job result belonged to the right tenant.

QA usually checks the expected tenant and does not replay the same flow under another customer boundary.
Logs show that the request succeeded, not whether the returned records belonged to the right tenant.
Infrastructure checks cannot prove application-level tenant separation or cache correctness.
A single valid response can hide broader leakage through exports, jobs, or shared services.

AUDIT RESPONSE

The audit replays tenant-sensitive requests across changed actor, tenant, role, object, and workflow context.

WHAT WE TEST

What the audit checks

We focus on the places where cross-tenant leaks actually happen in SaaS systems: reads, lists, exports, caches, jobs, and privileged workflows.

Tenant Boundary Coverage

API and object access

Tenant-scoped API reads
Tenant-scoped list and search
Nested resources
Shared schema tenant filters
Joins and includes
Cross-tenant object ID reuse
Bulk update and delete

Roles and admin workflows

RBAC and role drift
Admin and support access
Tenant switching logic

Exports and data output

Export and download scope
Shared report or analytics endpoint leaks metadata
Response overexposure

Jobs, queues, and caches

Cache key isolation
Background job tenant context
Queue and scheduled job boundaries

Evidence and traceability

Audit log tenant context
Data residency assumptions
Response and side-effect evidence

AUDIT FOCUS

High-Risk Paths First

The audit follows requests, objects, roles, exports, jobs, caches, and admin workflows to find where tenant context breaks.

Changed tenant context
Changed actor or role
Changed object ownership
Changed workflow path
Response and side effects checked

Request Audit Scope

What counts as a cross-tenant data leak?

A cross-tenant data leak is not only one customer seeing another customer's full record. In SaaS products, exposure can happen through reports, exports, cached responses, metadata, background jobs, search results, and privileged workflows.

Another tenant's row shows up in the wrong view

A row appears in a list, table, dashboard, or search result even though the caller is scoped to a different customer boundary.

An export mixes records from more than one customer

A CSV, PDF, report, or archive contains records that should have stayed inside one tenant.

A cached response is reused across tenants

A dashboard or API response comes back from the wrong tenant because the cache key or invalidation path did not include tenant context. See tenant-aware caching in SaaS.

Search metadata reveals another customer's activity

Counts, IDs, filenames, or search hints expose activity from a tenant that the user should not be able to infer.

A background job writes output into the wrong scope

A queue worker or scheduled job loses tenant context and generates output for the wrong account. See tenant-aware background jobs in SaaS.

Support or admin access crosses the boundary

A support view, impersonation path, or admin workflow opens data outside the intended account boundary. See Tenant Isolation Audit.

Analytics or reporting exposes another tenant's data

Aggregate endpoints, reporting jobs, or export summaries reveal data that should stay isolated to one customer.

Audit logs cannot prove which tenant was accessed

The event exists, but the evidence is too weak to prove the request stayed within the right tenant boundary. See preventing cross-tenant leakage and tenant isolation failures in SaaS.

HOW WE PROVE IT

How the audit works in practice

The goal is to prove the failure path with request pairs and tenant comparisons so engineering can fix the issue without guesswork.

PROCESS

How the audit proves access control issues

We compare valid requests against changed tenant, actor, role, token, and object context. The result is clear evidence of where access control holds, where it fails, and which paths should be fixed first.

TIMELINE

How we test tenant boundaries

Map tenants, users, roles, and flows

We identify the customer boundaries, roles, object types, and leak-sensitive workflows that matter most.

Collect baseline Tenant A requests

We capture requests that should succeed for the rightful tenant before any mutation is introduced.

Replay under Tenant B

We send the same request from another tenant and compare the result against the baseline.

Compare responses and exports

We check status codes, returned records, metadata, cached results, and export output.

Identify leak type

We classify whether the issue is read, list, export, cache, job, or admin related.

Review logging evidence

We check whether the system can prove which tenant was accessed or whether the evidence is missing.

Classify by customer risk

We separate narrow drift from real cross-tenant exposure so the team can prioritize the highest-risk paths first.

Common Failures

Common cross-tenant leak patterns we look for

These are the recurring failure modes that show up when the control is enforced in some places but not others.

Missing tenant filter in query

The data lives in the right table, but the query forgets to scope it to the active tenant.

Mixed records in a list endpoint

Search, list, or pagination responses return records from more than one customer.

Export includes another customer's data

CSV, PDF, or report generation returns records outside the caller's boundary.

Cached response reused across tenants

A shared response can leak if the cache key does not include tenant context.

Background job writes into wrong tenant scope

A worker processes the wrong records because tenant context was lost in the queue or scheduler.

Analytics endpoint leaks customer metadata

Aggregation or reporting routes reveal fields or counts that should stay isolated.

Support path bypasses tenant boundary

An internal or privileged flow is broader than intended and can cross customer lines.

Nested child object skips tenant validation

The parent appears valid, but the child object still needs its own tenant check.

Deleted tenant data appears in shared view

Old data still surfaces through direct requests or shared views when it should be gone.

Audit logs cannot prove tenant access

The event exists, but the log cannot show which tenant was accessed or whether the boundary held.

Comparison

Why this is not another multi-tenant security guide

Guides explain how tenant isolation should work. This audit tests whether your SaaS actually enforces it across real requests, roles, exports, jobs, caches, and admin workflows.

Guides / generic scanners

Explain common risks.

Give general advice.

May miss tenant-specific business logic.

Do not prove your live tenant boundary.

Do not provide reproducible request pairs.

Agnite tenant boundary audit

Tests your SaaS flows directly.

Replays requests across tenant, actor, role, and object context.

Compares real responses and side effects.

Provides evidence, severity, reproduction steps, and fix guidance.

Includes a retest checklist your team can rerun after fixes.

What this is not

Not generic vulnerability scanning. Not only database review. Not only infrastructure review. Not only source code review. Not a broad compliance checklist.

Who Should Care

Who should care about this audit

It matters most when the product already serves multiple customers and the team needs proof that data does not leak across them.

SaaS founders

You need proof that customer data stays inside the right boundary as the product grows.

CTOs

You need to know whether tenant boundaries are real across APIs, caches, jobs, exports, and admin workflows.

Engineering leads

You need a concrete audit target, a fix path, and a way to retest the flow after the change.

Enterprise-ready teams

Security review conversations often focus on tenant isolation, access controls, and data separation proof.

Teams with shared schemas or shared services

Shared infrastructure raises the risk of subtle leakage when enforcement drifts between layers.

Teams handling customer records

Reports, files, invoices, analytics, dashboards, exports, and workflows all need tenant-aware protection.

Teams adding workspace or organization features

The moment collaboration and account boundaries expand, the security model needs validation.

Related proof/resources

OPEN REPORT

Sample Audit Report

Open a polished example report showing the audit scope, tested authorization paths, risk summary, and recommended fixes.

Open report

VIEW FINDINGS

Sample Findings

Review 10 realistic SaaS security findings, including tenant isolation failures, broken role checks, exposed object access, and unsafe data responses.

View findings

OPEN CHECKLIST

Audit Checklist

Use the same checklist to review object access, tenant boundaries, RBAC rules, exports, webhooks, and sensitive response data before release.

Open checklist

OPEN LAB

Security Lab

See the lab scenarios behind the report, including how cross tenant access, IDOR, RBAC gaps, and audit logging issues are tested.

Open lab

FAQ

Questions buyers ask before they book the audit

Short answers for teams deciding whether they need focused cross-tenant leak testing or the broader security audit.

What is a cross-tenant data leak?

It is when one customer can receive another customer's data through a real application path such as a list, export, report, cache, or background job.

Is this the same as tenant isolation testing?

It overlaps heavily, but this page is broader. It looks at reads, lists, exports, caches, jobs, admin access, and the runtime exposure path.

Can logs miss cross-tenant leaks?

Yes. Logs often show that the request succeeded, but not whether the response contained another tenant's data or whether the cache or job path leaked it.

Do you test exports and reports?

Yes. Exports and reports are common cross-tenant leak paths because they often return more data than a single read request does.

Do you test caching and background jobs?

Yes. Cache keys and worker context are common places where tenant boundaries break under real traffic.

Do you need source code?

Not always. We can start from live requests and responses. Source access helps when the issue points to shared queries, cache keys, workers, or tenant propagation code.

What do we receive after the audit?

You receive findings, reproduction steps, evidence, risk explanations, and remediation guidance. If the issue is structural, the report will also point to the broader system changes that should follow.

Can you retest after fixes?

Yes. The same baseline and mutated requests can be replayed after remediation to confirm the tenant boundary now holds.

Final CTA

Test the tenant boundary before customers find the leak.

If your SaaS platform handles reports, exports, analytics, background jobs, or shared schema data, this is where you prove the control holds.

Review cross-tenant leak risk View broader security audit