Shared Database Isolation Audit
Shared tables are common in multi tenant SaaS, but one unsafe query path can still expose the wrong customer records. This audit tests whether tenant predicates survive ORM scopes, joins, reports, raw SQL, admin paths, and exports, then gives engineering request-level evidence, fix direction, and retest proof.
Shared database isolation fails across real query paths
The problem is usually broader than one missing filter. Shared schema queries have to stay scoped across every read path.
Tenant filters are repeated across many query paths, so scope drift often appears in one route while the rest of the product still looks correct.
ORM global scopes can drift or be bypassed when helper methods, repository shortcuts, or reporting code do not inherit the same tenant context.
Joins may scope the parent row but not the child rows, which is enough to return mixed tenant data from a query that looked safe at first glance.
Admin and reporting endpoints often reuse broader data access than the main UI because they were built for internal convenience first.
Exports can reuse unsafe queries or background jobs that no longer carry the original request's tenant predicate.
Auth and RBAC can look correct while one unsafe database query still returns another customer's records.
Why buyers care
For buyers, this is proof that privileged support access cannot expose or change another customer's data without the right tenant scope and audit trail.
Shared-schema workflows where tenant scope weakens
These are the shared database-backed workflows where tenant boundaries often weaken first.
List endpoints
Filters, sorting, and pagination can hide a missing tenant predicate in an otherwise normal query.
Detail endpoints
Nested records can leak wrong tenant rows even when the parent object is scoped correctly.
Search endpoints
Alternate search paths often bypass the same scope logic used in the main UI.
Reports and exports
Aggregate queries and export jobs can return mixed tenant rows even when the main UI looks clean.
Admin and support tools
Privileged lookup paths can surface cross tenant data if tenant context is not enforced end to end.
Background jobs and analytics
Async workers and metrics queries can lose the original scope before the result is produced.
Raw SQL and helpers
Manual SQL and repository helpers can drop tenant context even when the caller looks correct.
Read models
Denormalized views can mix tenant data if refresh jobs are not scoped correctly.
Boundary checks that match the scope buyers asked for
We test shared tables, tenant filters, unsafe joins, global query scopes, ORM filters, reporting queries, schema design risks, and the request paths that usually bypass the main UI.
Query Scope And Tenant Predicates
We test whether the tenant predicate survives the full request path. Failure looks like a scoped route returning mixed rows after filters or includes are added.
Joins, Nested Records, And Object References
We verify that parent and child rows stay in the same scope. Failure looks like a valid object that still pulls in another tenant's data.
ORM Scopes, Helpers, And Raw SQL
We test whether ORM filters still hold when helpers or raw SQL are used. Failure means the protection works in one path and disappears in another.
Reports, Exports, And Read Models
We review aggregate queries, export jobs, and read models for cross tenant exposure. Failure looks like files, summaries, or caches showing wrong tenant records.
Admin, Support, Search, And Filtering
We inspect privileged search and lookup paths plus filter mutations. Failure looks like admin tools or search results returning wrong tenant records.
Pagination, Sorting, And Edge Cases
We look for query variants that break scoping when page boundaries or sort keys change. Failure can hide mixed rows on later pages or alternate filters.
Tenant replay method
We use controlled tenant replay to show whether shared row scope still holds under a second context.
Identify Shared Database Workflows
Map shared-table reads, joins, exports, dashboards, and admin paths that depend on tenant scoping.
Select Tenant A and Tenant B Actors
Use two controlled tenant contexts so the comparison stays safe and meaningful.
Capture Baseline Requests
Record the normal tenant-scoped response before replaying the workflow under another context.
Replay the Request Under Another Tenant
Repeat the same workflow with a different tenant context and compare the result.
Compare the Response Shape
Compare records, IDs, counts, nested objects, exports, and status codes.
Document the Failure
Tie the issue back to the route, evidence, severity, and fix direction.
Retest After Remediation
Replay the same comparison after the fix so the boundary can be verified.
Request-level evidence buyers can hand to engineering
The report gives engineering enough detail to replay the request pair, understand the boundary failure, and retest after the fix.
Tested route or workflow
Shared-table list, detail, reporting, or export request path
Tenant context used
Tenant A replayed against Tenant B with controlled roles
Baseline response summary
Baseline request returns only the expected tenant-scoped rows and nested objects
Mutated response summary
Equivalent request under the second tenant returns mixed or wrong rows, counts, or exports
Leaked record type
Shared table rows, nested child rows, report rows, or exported file contents
Affected tenant boundary
Shared database row scope, join scope, or export boundary
Expected result
The second tenant should receive a scoped response with no other tenant data present
Actual result
The response proves the wrong tenant context survived into the database query or export path
Severity
High when records cross accounts, critical when sensitive customer data is exposed
Engineering fix direction
Reinforce tenant predicates, join scoping, helper behavior, and export query paths
Safe reproduction notes
Request pair, tenant context, and response differences without exploit detail
Retest result
The replay no longer returns cross tenant rows after remediation
Want this tested against your shared schema?
Use the focused review for a known shared database risk, or roll it into the full Multi Tenant Security Audit.
Focused shared database review
Best for teams already suspecting shared database isolation is the weak area.
From EUR 750
Shared-schema SaaS apps, ORM filters, raw SQL, reports, exports, and tenant-scoped query helpers.
Included inside the full Multi Tenant Security Audit
Focused on shared tables, query scopes, joins, exports, and shared row scope
Useful when request-level evidence is needed before a broader review
Focused audit vs full multi tenant security audit
Use the focused scope when shared tables are the concern. Use the full audit when the product needs a wider tenant isolation review.
Narrower scope for export, report, and file delivery risk.
Broader tenant boundary review across the product.
Signals you may need this audit
If any of these describe the product, the shared database boundary is worth testing directly.
Shared database or shared schema architecture
One missed predicate can expose more than one tenant.
Multiple workspaces, accounts, or organizations
More tenant groups create more places for scope drift to hide.
Custom reporting or exports
Generated outputs often use separate queries and deserve a boundary check.
Heavy use of ORM global filters
Global scopes help, but helpers, raw SQL, and alternate query shapes can bypass them.
Raw SQL mixed with ORM code
Mixed access patterns make it easier for one path to forget the tenant predicate.
Admin dashboards or support tooling
Privileged workflows need their own review because they see more data.
Recent move from single tenant to multi tenant
Old global-access assumptions often survive the migration longer than expected.
Enterprise customers asking about isolation
If buyers are asking about isolation, they need request-level proof.
Previous authorization or RBAC bugs
Earlier access-control bugs are a strong signal to test shared-schema risk.
Audit scopes and guides
Commercial audit paths
Adjacent commercial scopes buyers compare when shared tables are the concern.
Multi Tenant Security Audit
The broader audit that keeps shared schema findings inside the larger tenant boundary review.
Review full multi tenant security auditSample SaaS Security Audit Report
See the evidence format buyers receive before they book a live audit.
View sample reportSaaS Tenant Isolation Audit
A narrower boundary review for tenant-scoped reads, lists, exports, and nested objects.
Review tenant isolation auditCross Tenant Data Leak Audit
Use this when the shared database risk already looks like a wider exposure problem.
Review cross tenant leak auditSupporting reading
Technical guides for the same shared-table risk.
Shared Database Tenant Isolation
Practical walkthrough of why shared tables fail when tenant predicates drift.
Read shared database guideTenant ID Filtering in SaaS
How ORM filters and query helpers should keep tenant scope attached everywhere.
Read tenant filtering guideTenant Scoped Queries in SaaS
How to reason about query scoping, joins, and list endpoints in a shared database.
Read tenant scoped queries guideSaaS Database Schema Patterns
How schema shape affects tenant isolation, joins, and row-level leakage risk.
Read schema pattern guideQuestions buyers ask about shared database isolation
Short answers for teams deciding whether they need a targeted shared table review or the broader audit.
What does shared database isolation testing prove?
It shows whether tenant boundaries survive real request paths in a shared database, not just a design review or a code comment about tenant filters.
Is this different from a full multi tenant security audit?
Yes. This scope focuses on shared tables and the query paths around them, while the full audit covers a wider tenant boundary review across the product.
Do shared tables always create security risk?
No. Shared tables are common, but they become risky when tenant predicates do not survive every query path, join, helper, export, or report.
Do you review ORM filters and global scopes?
Yes. We test ORM global scopes and the paths that can bypass them, including helper methods and raw SQL.
Can raw SQL bypass tenant isolation?
Yes. Raw SQL can skip the ORM protections, so it needs its own tenant boundary review instead of relying on the calling code.
Can reports and exports leak data separately from the main app?
Yes. Reporting jobs, dashboard queries, and export flows often use different data access paths than the main UI.
Can this catch issues automated scanners miss?
Yes. Automated scanners usually do not prove tenant boundary failure under replayed request context the way this audit does.
Should we do this before enterprise sales?
Yes. If enterprise buyers care about data isolation, this scope gives you a concrete signal before the sales cycle depends on it.
Does this include retesting?
Yes. The same request pair is replayed after remediation so the report can show that the tenant boundary now holds.