> Source: https://planckproof.ai/penetration-testing-for-saas  |  Plain-Markdown twin of the page.

SaaS

# 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.

[Get a Quote](https://planckproof.ai/quote)

[SOC 2 Guide](https://planckproof.ai/soc-2-penetration-testing)

The SaaS Attack Surface

## 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.

Tenant isolation

### 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.

Authorization

### 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.

Identity and SSO

### 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.

Where Operator Fits

## 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](https://planckproof.ai/tenant-isolation-testing) page.

[Multi-tenant use case](https://planckproof.ai/use-cases)

Example Finding

## Cross-tenant BOLA on organization membership

Here is what a missing tenant check looks like as one proven finding, not a hypothetical.

HIGH

Org A's token lists Org B's members and roles

1. Authenticated as an ordinary member of Org A and called `GET /api/v1/orgs/org_a3f21/members` with Org A's own orgId: returned Org A's member list, a correct 200 OK.
2. Replayed the identical endpoint and bearer token, substituting Org B's orgId in the path: `GET /api/v1/orgs/org_b91f4/members`.
3. The endpoint returned `200 OK` with Org B's full member list, including each member's role and email domain, without ever checking that the caller's token was scoped to `org_b91f4`.
4. 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>"
```

Severity

High · CVSS 7.7

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Verified

Reproduced 2 of 2

Standard

OWASP API Security Top 10, API1 BOLA

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](https://planckproof.ai/bola-testing) 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](https://planckproof.ai/proof) page.

Illustrative example, not a specific customer result.

FAQ

## 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](https://planckproof.ai/industries).

Get Started

## Prove your tenant boundaries hold

Point the agent at your platform and get continuous proof that one customer cannot reach another.

[Get a Quote](https://planckproof.ai/quote)

[SOC 2 Penetration Testing](https://planckproof.ai/soc-2-penetration-testing)