SaaS Multi-Tenant Isolation Assessment
In a multi-tenant SaaS platform, one broken isolation boundary means one customer reading another's data — the single most damaging bug class you can ship. We attack your tenant boundaries specifically and systematically, across application, API, data and infrastructure layers.
Verified Solvex Specialist
Verified by SolvexDirect specialist contact for Solvex engagements
What this means. An authorized Solvex administrator registered and approved this exact public identity. What it does not. Solvex has not inspected the account on the platform, and this is not the platform's own verification.
Solvex specialists never ask for your passwords, recovery phrases, one-time codes, or payments to a personal account. Work, scope and invoices are agreed in writing through the official channels on this site.
Signed authorization required. This engagement is performed only against systems you own or are contractually authorized to have tested, under an agreed scope. See the responsible testing policy.
What's covered
- Cross-tenant access testing across every role and permission tier
- Tenant-context handling in APIs: IDOR/BOLA with tenant identifiers, header and token scoping
- Data-layer isolation: row-level security, schema separation, shared-cache leakage
- Background jobs, exports, webhooks and integrations as cross-tenant channels
- Infrastructure isolation: shared compute, storage and queue boundaries
- Tenant lifecycle edge cases: onboarding, offboarding, suspension, data deletion
What you receive
- Technical report of every isolation weakness with cross-tenant proof of impact
- Severity ranking weighted for tenant-data exposure
- Architectural recommendations for durable isolation, not just spot fixes
- Free retest of remediated findings
- An isolation test suite specification your team can automate in CI
Evidence and reporting
How the work is kept honest- Evidence, frozen at issuanceFindings tie to something observed. When the report is issued, the evidence behind it is frozen in the same transaction and cannot be edited afterwards.
- A signed reportAn Ed25519 signature covers both the report content and the delivered file. Alter a byte of either and verification fails.
- Signed scope firstTesting starts only after written scope and signed authorization for systems you own or are entitled to have tested.
Anyone holding a Solvex report can verify it publicly without seeing its contents.
Our boundaries
What this engagement does not do, stated before it starts.
- Testing uses seeded test tenants — never real customer data
- Only platforms you own or are contractually authorised to test
- No denial-of-service against shared infrastructure without written consent
- Findings are confidential; cross-tenant proofs are destroyed after the engagement
How this engagement runs
- 01
Intake
Tell us the system, the goal and the constraints. If the work is not a good fit, we say so before anyone is invoiced.
- 02
Scope and authorization
Written scope and signed authorization before anything is touched. Security testing runs only against systems you own or are contractually entitled to have tested.
- 03
Investigation or build
Specialists matched to the work. Findings are proven by hand — scanner output is a lead, never a finding.
- 04
Evidence
Every finding ties to something observed. When a report is issued, its evidence is frozen in the same transaction, so what backed the report cannot change afterwards.
- 05
Delivery
A signed report: an Ed25519 signature over both the content and the file, with a short verification reference you can read down a phone.
- 06
Verification and retest
Anyone holding the report can verify it publicly without seeing its contents. Fixes are retested as part of the engagement — “fixed” means we confirmed it.
Questions we are asked
- We already had a pentest. Why a separate isolation assessment?
- General pentests sample broadly and rarely have time to attack tenant boundaries exhaustively. This engagement does one thing deeply: multiple seeded tenants, every role, every data path, every async channel — because for a SaaS business, cross-tenant leakage is an existential bug class that deserves dedicated coverage.
- How do you test without touching real customer data?
- We work in a staging environment or with dedicated test tenants seeded with synthetic data. Every cross-tenant proof uses our own seeded tenants on both sides of the boundary — real customer data is never part of the method.
- What's the CI test suite specification?
- Each confirmed finding class becomes a specified regression test — the request pattern, the tenant setup, the expected denial. Your engineers implement them in your test framework so isolation is continuously verified on every build, not just at assessment time.
Related services
Cloud / DevSecOps
Cloud Penetration Testing
The cloud shifts the security model, and misconfigurations are the new default vulnerability. We test your AWS, Azure or Google Cloud environment for exploitable weaknesses — from exposed storage to over-privileged roles to escape paths.
Offensive / Testing
API Penetration Testing
APIs are where modern breaches happen. We test your REST, GraphQL and gRPC endpoints for broken authorisation, data leakage and logic flaws, so the interfaces powering your apps and partners can't be turned against you.
Cloud / DevSecOps
Kubernetes Security Review
Kubernetes is powerful and easy to misconfigure into a breach. We review your clusters against security best practice — RBAC, network policies, pod security, secrets — so your orchestration platform isn't your soft underbelly.