Every multi-tenant SaaS application makes the same promise: your data is yours, and no other customer can reach it. That promise is enforced in hundreds of small places — every query filter, every object lookup, every export, every webhook, every background job — and it only takes one of them to be missing.
Testing that promise properly is what we do. It is also the flaw class automated tools cannot find, because nothing about the request is malformed: it is a perfectly valid call from a legitimately authenticated user, asking for a record that happens to belong to somebody else.
Who this is for
- You run a multi-tenant platform and a prospect, customer or auditor has asked how you know tenants are isolated.
- You are going through SOC 2, ISO 27001 or an enterprise security review and need a real assessment rather than a scan report.
- Your product has grown roles, workspaces, org hierarchies, delegated admins and partner access — and nobody has systematically tried to cross those boundaries.
- You are raising, or being acquired, and security due diligence is on the critical path.
What we test in a SaaS platform
Cross-tenant isolation
The core of the engagement. Working from accounts in two or more separate tenants, we attempt to reach one tenant’s data from the other — through object identifiers, search, reports, exports, bulk endpoints, file downloads, webhooks, notification payloads, audit logs and integration callbacks. Anywhere your platform moves data, we test whether the tenant boundary moves with it.
Roles, permissions and privilege boundaries
Every role against every function: can a viewer write, can a member reach admin endpoints, can a billing user read customer records, can a deactivated or suspended user still act? Invitation and onboarding flows get particular attention — they routinely allow privilege selection that the UI never offers.
The API, tested directly
Your UI constrains what gets sent; an attacker is not so limited. We exercise the API outside the interface — mass assignment on tenant and role fields, endpoints the UI never calls, method confusion, and object references that accept another tenant’s identifier. See API penetration testing.
Subscription, quota and plan enforcement
A commercial boundary is a security boundary in SaaS. Can a free tenant enable paid features, exceed seat or usage limits, bypass rate limiting, or extend a trial by manipulating the request rather than the plan?
Business logic and workflow
Can approval steps be skipped, replayed or reordered? Can a record be moved between tenants? Can a shared or public link outlive the permission that created it? Can a race condition double-spend a credit or seat?
Authentication, SSO and sessions
SAML and OIDC integration weaknesses, tenant-scoped login bypasses, session handling across workspace switching, token scope and revocation, and API key lifecycle. Tokens that carry authorization decisions rather than identity are a recurring, high-impact finding (a real example).
Why a developer-led team finds what others miss
Most security firms are staffed by security people who learned about software. We came at it from the other direction, and it shows in what we find.
- We write code. Not scripts — software. We build and maintain CybeRapid, the platform our testers work on, in-house: the discovery, the role matrices, the evidence capture and the reporting are ours, and they improve because the people using them are the people writing them.
- We read code the way its authors do. Our founder wrote Managed Code Rootkits (Syngress) about attacking the .NET CLR, the JVM and Android’s Dalvik — the layer underneath the application. Understanding a runtime that well changes what you notice in the application running on it.
- We taught developers for a decade. Around around 5,000 developers learned secure coding and application hacking from us, including five consecutive years teaching at Black Hat USA. It is why our reports are written for the person who has to fix the problem, and why we can defend a finding to the engineer who wrote the code.
- Engineers who leave here build security products. People from this team went on to found companies acquired by Snyk, Check Point, Contrast Security and Zimperium — the pattern is documented.
This matters for one practical reason. The findings that decide a release are not pattern matches; they are consequences of how your system is built — a role model with an exception in it, a workflow that can be reordered, an API that trusts a value it should have recalculated. Recognising those requires reading a system the way an engineer does, then attacking it the way an adversary does.
How a SaaS engagement runs
- Scoping. We map your tenancy model first — how tenants, organisations, workspaces and roles actually relate. That model determines the test, and it is the conversation most vendors skip.
- Access.At least two separate tenants, with an account for every role in each. This matters more than anything else you give us: with a single tenant, cross-tenant testing is impossible and the most valuable findings simply cannot be discovered.
- Testing. A role-versus-object matrix worked through systematically rather than sampled, accelerated by our own platform, CybeRapid, so more of our testers’ time goes on judgement.
- Reporting, remediation support and retest — every reported finding verified after your developers fix it, as part of the engagement.
What your customers and auditors get
A report that answers the question enterprise buyers actually ask: can another customer of yours reach my data, and how do you know? Findings carry reproduction steps, real business impact and concrete remediation — written for the engineers who have to fix them. Our reports are regularly used for SOC 2, ISO 27001, PCI-DSS and enterprise security reviews.
Common questions
Do you need access to more than one tenant?
Yes, and it is the single most important thing you can give us. Cross-tenant isolation cannot be tested from inside one tenant. Two tenants, each with an account per role, makes the difference between a thorough test and a superficial one.
Can you test in production, or do you need staging?
Staging that mirrors production is ideal, particularly because cross-tenant testing means deliberately trying to reach data across a boundary. Where production is necessary we agree the boundaries in writing first – what is in scope, which techniques are excluded, and who to reach immediately.
How long does a SaaS penetration test take?
Usually one to three weeks, driven by the number of roles, tenancy layers and integrations rather than by page count. We scope it with you and commit to the timeline.
Will this satisfy our SOC 2 auditor or a customer security review?
Yes – it is one of the most common reasons clients engage us. Tell us which framework or customer questionnaire you are answering and we will make sure the report addresses it directly, including the retest evidence that closes findings out.
We already run scanners and a bug bounty. What does this add?
Scanners find known patterns and bounty hunters find what is reachable without credentials. Neither systematically works a role-versus-object matrix across tenants, because that requires multiple provisioned accounts and an understanding of what your product is supposed to allow. That is precisely where tenant isolation fails.
What does it cost?
It depends on the tenancy model, the number of roles and whether mobile clients and integrations are in scope. We scope properly before quoting, so the number you get is the number you pay – and we will tell you if a smaller engagement would answer your question.
Talk to us about testing your SaaS platform
Expert-led testing of complex authenticated applications – multi-tenant isolation, authorization/BOLA, business-logic and workflow abuse, complex role models – with developer-usable remediation.
Tell us what the application does and what worries you about it. We will come back with scoping questions, a clear proposal and a realistic timeline — and if a test is not what you need yet, we will say so. Get in touch.
See also: web application testing · API penetration testing · our full methodology.