SaaS penetration testing for multi-tenant products
SaaS penetration testing for multi-tenant products: eight areas we test, the two-tenant method, a sample finding, and what the report contains.
Short answer
SaaS penetration testing checks that one customer cannot reach another customer's data, and that roles, invitations, billing and admin functions behave as designed. Excession Labs uses a two-tenant method: two separate tenants, several roles each, and read-back proof from a second account. You get a written report with evidence, controls and fix guidance.
If you sell software to businesses, each customer expects you to keep their data apart from everyone else's. SaaS penetration testing checks that separation, plus the paths enterprise buyers ask about: roles, invitations, billing and admin access.
What do we test in a SaaS product?#
Broken access control is first on the OWASP Top 10:2025. In SaaS it can show up as a tenant boundary that holds in the interface but not in the API.
| Area | Question we answer |
|---|---|
| Tenant isolation | Can a user in tenant A read, change or delete a record in tenant B by changing an ID? |
| Search, export and reports | Do search results, CSV exports and dashboards filter by tenant on the server? |
| Files and attachments | Can a file URL from tenant A be opened by tenant B or by an anonymous user? |
| Roles and permissions | Can a Viewer do what an Editor does? Can a Member do what an Admin does? |
| Invitations and sign-up | Can an invite be reused, redirected to another tenant, or accepted with a different role? |
| Billing and entitlements | Can a user reach paid features, exceed seat or usage limits, or abuse trials? |
| Admin and support paths | Can an ordinary user reach internal admin routes, impersonation or feature flags? |
| Integrations | Do API keys, webhooks and OAuth apps stay inside their tenant and scope? |
The SaaS work sits on top of the checks described in web application and API testing.
How does the two-tenant method work?#
We ask for two tenants with at least two roles in each, and create test objects in each tenant. Then we replay every request from tenant A with tenant B's identifiers, and the reverse. We repeat it for every role.
Each result is compared with controls: a nonexistent ID, a wrong record type, another account's token and an anonymous call. A cross-tenant effect counts only when we read the changed or exposed record back through the second tenant's session. The guide on multi-tenant isolation testing has the full matrix.
Sample finding
This is a demonstration. It uses a fictional app, Harbor Notes Teams, and no real customer system was tested.
Finding S-03: The export endpoint ignores the tenant (High). A user in tenant t_acme requests an export with a report ID from tenant t_globex.
POST /api/exports HTTP/1.1
Host: app.example.com
Cookie: session=<acme-admin-session>
Content-Type: application/json
{"report_id":"rpt_55120"}
HTTP/1.1 202 Accepted
{"export_id":"exp_9021","status":"queued"}
The download from exp_9021 contained rows owned by t_globex (Observed, read back with the acme session). Controls: report rpt_00000 returned 404, and an anonymous call returned 401. Fix: resolve the report by tenant and ID together, in one query.
What do you get?#
You get a report in HTML, PDF and Markdown, with proof-of-concept scripts. It contains an executive summary with priority actions, a findings table, and one section per finding with impact, verified results, reproduction and remediation. A "Controls that held" section lists the isolation checks that passed, which enterprise buyers ask about. We can retest fixes (see retesting). For buyer reviews, see customer security review.
What do we need from you?#
- Written authorization from the system owner.
- Two test tenants with test data, marked as test data.
- At least two roles per tenant, with credentials for each.
- A description of the role model and plan tiers.
- Documentation or a route list for the API.
- Any SSO, SCIM or webhook setup that is in scope, plus a contact for questions.
What changes the quote?#
The number of roles, tenant-scoped objects and integrations drives effort, as do admin and billing paths, SSO, the API surface and whether you want a retest. We publish no prices and quote after a short call and a written scope (see pricing).
Ready to scope a SaaS test? Request a pentest.
Questions
Why does a SaaS product need a different test from a normal web app?
A SaaS product serves many customers from one system. The worst failure is one tenant seeing another's data. A normal test may use one account and miss this. We test with two tenants and several roles so cross-tenant access shows up.
Do you need production data?
No. We ask for test tenants with test data that you mark as such. We do not need real customer records. If you can only test in production, we use test-owned tenants and say so in the scope.
Will you test billing and plan limits?
Yes, where they are in scope. We check whether a user can reach paid features without the plan, change seat counts, or reuse trial and coupon flows. Tests that call a paid third-party API are bounded and their cost is stated in the report.
Do you test single sign-on and SCIM?
If SSO or provisioning is in scope, we check how identities map to tenants and roles. We need a test identity provider or a staging configuration. Tell us at scoping which protocols you support.
Sources
- OWASP Top 10:2025, A01 Broken Access Control (checked 9 November 2026)
- OWASP API1:2023 Broken Object Level Authorization (checked 9 November 2026)
Need a pentest you can act on?
Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.