Penetration testing for SaaS platforms
In a multi tenant platform, tenant isolation is the product, and one flaw affects every customer at once. SaaS penetration testing proves that the boundaries between your customers hold, that authorization is checked everywhere, and that your SOC 2 story is backed by evidence, continuously as you ship.
What actually breaks in multi tenant software
The exposures that matter most for a SaaS platform are the ones that cross a customer boundary or bypass a permission.
One customer reaching another
Whether shared infrastructure, identifiers, or storage let one tenant read or act on another tenant's data. The single highest impact class for SaaS.
Object level access
Identifiers that are not checked against the caller, so changing a number in a request exposes a record that was never yours. The most common SaaS leak.
Auth flows under attack
Single sign on, OAuth, and SAML flows, session handling, and the account boundaries an attacker probes to escalate from one login to many.
- Cross tenant reachability tested on every change.
- Object level authorization, the most common SaaS flaw.
- SSO and session boundaries probed for escalation.
- Continuous evidence for your SOC 2 audit period.
Isolation tested the way a paying tenant would try to break it
Your schema and features change constantly, and each change can quietly open a path between customers. Operator re tests tenant isolation and authorization continuously, the way a real customer would try to reach the account next door.
Every finding arrives with the reproduction evidence and CVSS rating your engineers and your SOC 2 auditor both accept. For a deeper look at how the boundary checks work, see our multi-tenant isolation testing page.
Cross-tenant BOLA on organization membership
Here is what a missing tenant check looks like as one proven finding, not a hypothetical.
- Authenticated as an ordinary member of Org A and called
GET /api/v1/orgs/org_a3f21/memberswith Org A's own orgId: returned Org A's member list, a correct 200 OK. - Replayed the identical endpoint and bearer token, substituting Org B's orgId in the path:
GET /api/v1/orgs/org_b91f4/members. - The endpoint returned
200 OKwith Org B's full member list, including each member's role and email domain, without ever checking that the caller's token was scoped toorg_b91f4. - Repeated the swap against a third organization's orgId to confirm the check was missing everywhere, not one route.
GET /api/v1/orgs/org_b91f4/members HTTP/1.1
Host: api.example.com
Authorization: Bearer <ORG_A_TOKEN>
HTTP/1.1 200 OK
Content-Type: application/json
{ "org_id": "org_b91f4", "members": [{ "user_id": "usr_50713", "role": "admin", "email_domain": "orgb-example.com" }] }
curl -s https://api.example.com/api/v1/orgs/org_b91f4/members \ -H "Authorization: Bearer <ORG_A_TOKEN>"
The orgId in the path was treated as trusted input instead of a value to check against the caller's own membership, the pattern behind most object level authorization failures in multi tenant APIs.
This is the shape most cross tenant leaks take in a SaaS API: the route works, the response is a clean 200 OK, and the only thing missing is a check that the identifier in the path belongs to the caller. A scanner sees a valid response and moves on. A human reviewer sampling endpoints by hand may never think to try a second organization's id from a first organization's session, especially on a membership or settings route that looks read only and low risk.
Operator tests this on every deploy, not once a year: it authenticates as multiple tenants, systematically swaps every identifier in every path and body against every other tenant it holds credentials for, and only reports what it can reproduce against the live target, with the request and response evidence above attached. That is the same discipline behind every finding the agent produces, detailed on the proof page.
Illustrative example, not a specific customer result.
Common questions
Why do SaaS companies need penetration testing?
Because one flaw affects every customer at once. In a multi tenant platform, a single access control mistake can let one customer reach another customer's data, and your buyers, and their SOC 2 auditors, expect you to prove that cannot happen.
What does SaaS penetration testing cover?
Tenant isolation, object level authorization, authentication and single sign on flows, the API layer, and the shared infrastructure behind them. The focus is the boundaries that keep customers separate and the identifiers that should always be checked.
How does it help with SOC 2?
A penetration test is standard evidence for the SOC 2 Security criterion, and continuous testing produces the dated, ongoing record auditors increasingly expect across the audit period. See our SOC 2 guide for detail.
Not a SaaS platform, or need coverage for another sector too? See API penetration testing by industry.
Prove your tenant boundaries hold
Point the agent at your platform and get continuous proof that one customer cannot reach another.