SaaS penetration testing
Penetration testing built for multi-tenant SaaS
The bug that ends a B2B SaaS company is not a missing header. It is one customer reading another customer's data, and finding it requires two tenants and someone who understands your permission model.
The context
Why this is different
Generic application penetration testing applies to SaaS, and it also misses the thing that matters most. A tester working from a single account cannot detect that changing an identifier returns another organisation's invoice, because both responses look identical from the inside: valid JSON, 200 status, well-formed data.
That is why we structure SaaS engagements around tenancy from the start. Two independent organisations, populated with distinguishable data, every role provisioned in both, and a systematic replay of every request from one context into the other with the responses compared rather than the status codes.
The second thing conventional testing under-covers is the indirect path. Product teams reason carefully about the primary read endpoint and then leak the same records through a CSV export, a webhook payload, a notification email, a search index or an internal admin view that authenticates but never authorises.
What we look for
The failure classes that actually show up.
Cross-tenant data access
The highest-impact class in B2B SaaS and the one enterprise security reviewers ask about first. Usually an identifier trusted from the request without a scoping check, sometimes a query that filters after fetching rather than before.
GET /api/v2/invoices/4192 // 200 with another organisation's invoice // identical shape to a legitimate response
Role boundaries that do not hold
A read-only member performing writes, a billing role reaching product data, or a custom role whose permissions were never actually enforced server-side because the UI hides the controls.
Invitation and membership flows
Invitation tokens that do not expire or are not bound to the invited address, self-service role elevation during acceptance, and the ability to add yourself to an organisation you were never invited to.
SSO and SCIM implementation
SAML assertion handling, unsigned or improperly validated responses, OIDC state and nonce handling, and SCIM endpoints that provision or elevate users without adequate authentication. Enterprise features frequently ship with less scrutiny than the core product.
The indirect data paths
Exports, webhooks, notification emails, search indexes, audit logs and support tooling. All of them read the same records and all of them are frequently outside the authorization layer the primary endpoints use.
API surface beyond the UI
Undocumented endpoints, previous API versions still routed, GraphQL introspection exposing mutations the interface never calls, and mass assignment on update endpoints that accept fields the client should not control.
Business logic and subscription state
Feature gates enforced only in the frontend, seat limits bypassable through the API, trial extension through repeated signup, and credit or usage counters that can be manipulated.
File handling and storage
Uploads that reach a shared bucket without tenant prefixing, pre-signed URLs with excessive lifetime or scope, and direct object access that skips the application's checks entirely.
How we test it
The engagement.
- 01
Model the permission system
Before testing, we document what each role is supposed to reach in each tenant. Without that, cross-tenant testing produces noise rather than findings, because we cannot tell an authorised response from an unauthorised one.
- 02
Provision and populate
Two independent organisations with distinguishable data and every role instantiated in both. Distinguishable matters: the data must make it obvious in a response which tenant it came from.
- 03
Enumerate the full API surface
From authenticated positions, including endpoints the interface never calls. Build output, mobile clients, older API versions and GraphQL schemas all reveal surface the UI hides.
- 04
Cross-tenant and cross-role replay
Every request replayed in every other context, with responses diffed rather than status codes checked. This is the core of the engagement and it is not meaningfully automatable without your permission model.
- 05
Follow the indirect paths
Exports, webhooks, emails, search, audit logs and admin tooling tested against the same boundaries as the primary endpoints, because they usually are not.
- 06
Report, fix, retest
Findings with reproduction steps and severity justified by exploitability and business impact. After you remediate we retest every one and reissue the report, included in the price.
What you get
Deliverables
- From
- $4,500
- Typical duration
- 1 to 3 weeks
- Executive summary written for a board or an enterprise customer
- Technical findings with reproduction steps and evidence
- Tenant isolation assessment covering direct and indirect paths
- Authorization matrix showing what each role can actually reach
- API surface inventory, including endpoints not exposed by the UI
- Free retest and reissued report confirming fix status
- Customer-shareable attestation letter for security questionnaires
Questions
The ones engineers ask.
Scanners find known-pattern issues and they are worth running. They cannot determine that invoice 4192 belongs to another tenant, because that requires knowing which tenant should own it. Every finding in the tenancy category above needs two accounts and a human comparing outputs.
We prefer a production-like staging environment with representative data, which lets us test destructively. Where only production is available we agree strict rules of engagement: rate limits, excluded actions, a named contact reachable throughout and a defined stop condition.
That is what the attestation letter is for. It confirms scope, dates, methodology and remediation status without disclosing exploitable detail, which is what security reviewers actually need. The full technical report stays with you.
One to three weeks of testing depending on the size of the API surface and the number of roles, with the report inside five working days of completion. Retesting happens after you deploy fixes and adds no cost.
Two organisations in a staging environment, accounts for every role in both, any API documentation you have, and a technical contact for questions. If the environment is IP restricted we will need our testing ranges allowlisted.
Know exactly what an auditor, and an attacker, would find.
Tell us what you need certified or tested. We will scope it properly, quote a fixed price, and tell you honestly if the timeline you have in mind is realistic.
No sales sequence. A scoping call and a written proposal cost nothing.