SaaS Penetration Testing: Scope, Tenant Isolation and Choosing a Provider

The scenario below is hypothetical, but it will feel familiar. A small B2B procurement platform is about to sign a contract with a large customer. The customer's security team sends a questionnaire with one line that matters: "Attach the results of a penetration test performed in the last twelve months." The deadline is tight, so the team orders the fastest option on offer — an automated scan of the main domain with a PDF report. The report lists a couple of outdated headers and a TLS version warning; the questionnaire is closed and the contract is signed.

A few months later, an administrator at one of the customers exports a quarterly report and finds rows belonging to another company. The export background job accepted the organisation ID from the request without checking the initiating user’s rights to that organisation and the exported objects. This particular scan did not reveal it: the scanner had one account in one tenant, and export was not among the checks it performed.

This is an illustration, not a description of a real incident. But it shows the essential point: in SaaS serious defects can live on the boundaries between customers, roles and asynchronous processes, so the scope must reach those boundaries. Below we cover what such a test includes, how to work with findings and how to choose a provider.

How a SaaS pentest differs from testing an ordinary website

A penetration test is an authorised, time-bounded assessment: specialists look for vulnerabilities in a product, its APIs and its environment, and safely demonstrate the consequences of exploiting them. The NIST SP 800-115 guide places penetration testing alongside scanning and other technical assessment techniques, and describes their purpose as finding vulnerabilities and verifying compliance with policies and requirements. For a SaaS company both sides matter: findings that are then remediated can reduce risk, while results bounded by the test provide material for conversations with customers and auditors.

At the same time, a pentest is not a certification, an attestation or an auditor's opinion. The report describes what could and could not be demonstrated on a specific build, in a specific environment, with specific accounts and within the checks actually performed. A discovered way to read another customer's data proves that this is possible under the observed conditions. The absence of critical findings after a limited number of days does not prove that there are no critical problems.

The target of a SaaS test is not one website but a browser application, public, partner and internal APIs, login and single sign-on, an admin console, tenant provisioning, billing, integrations and a code delivery pipeline. When customers run on shared code and infrastructure, one authorisation defect can affect several of them at once. That shared blast radius is what calls for a different scope.

The attack surface: from HTTP sessions to background jobs

Almost everything in a SaaS product goes through HTTP. The protocol does not keep state between requests, and MDN describes how cookies add it. But sessions are not "forbidden" over HTTP: an application can store a session on the server and link it to requests through an identifier in a cookie, or use signed tokens. What matters to the tester is how the product turns independent requests into a user, a role and a tenant — and where that link breaks.

Sessions, cookies and tokens

Testing starts with the session lifecycle: creation, refresh, termination on logout and password change, and what happens after a user is removed from an organisation. Cookie attributes, token revocation and the source of the tenant identifier get separate attention. Where the identifier is carried does not by itself determine security: a user may legitimately select an organisation in a header or parameter. The server must bind that selection to the verified identity, current membership and permission for the specific action and object; storing a tenant in a session or signed token does not remove the need for those checks.

APIs deserve no less attention than the user interface. The 2023 edition of the OWASP API Security Top 10 distinguishes three levels of authorisation: access to an object, to individual properties of an object, and to functions. A user may have no right to open another customer's order yet receive its fields through a nested object, or may not see the admin button yet successfully call the corresponding method directly. Unrestricted resource consumption and access to sensitive business flows are called out separately — for example, mass creation of trial tenants. More in our piece on REST API security assessment.

Browser headers: what they protect and what they don't

MDN describes several browser-side mechanisms. Content Security Policy helps detect and mitigate some attacks, including cross-site scripting and data injection. CORS determines whether a script from another origin may read a response, but it is not server-side authorisation: depending on the method, credentials and endpoint behaviour, a request from another site can reach the API and perform an action even if the browser never hands the response to the script. Cross-Origin Resource Policy restricts loading of response bodies in certain no-cors scenarios, but does not stop requests from being sent. Permissions Policy controls a page's access to browser features.

A useful test checks not whether the headers are present, but whether they match the product's real behaviour. A broad list of allowed origins combined with credentialed requests is assessed against which origins are trusted, what data the endpoint returns and whether credentials can be used; the significance of a missing CSP likewise depends on whether the page handles untrusted content and which exploitation paths exist. Error responses are worth examining too: verbose messages sometimes reveal internal identifiers or the very fact that an object exists in another tenant.

Human and service credentials

Login, sign-up, MFA, SSO, password reset and invitations are a classic part of scope. But there are also service credentials: customer API keys, integration tokens, webhook signing secrets, OAuth connections, accounts used by background workers. MFA protects a person at login and says nothing about how an integration key is restricted and revoked. For the SSO protocol in use, separately test the signatures and keys, issuer and audience, redirect URI or RelayState/state that it defines, along with account and tenant binding and creation and termination of the local session. If one customer's key opens another customer's resources, or keeps working after the integration is disconnected, severity depends on the accessible data, actions and number of affected tenants — just as it does for an authorisation bypass in the interface.

Tenant isolation — the defining boundary of SaaS

The core of a SaaS pentest is verifying that one customer's data and actions are inaccessible to another, and that roles within a customer are separated as intended. Direct cross-tenant testing needs at least two tenants; testing horizontal and vertical moves within a tenant needs the roles defined by the actual model, such as user, manager and organisation administrator. The concrete set follows the product's permissions matrix.

The tenant boundary does not run only through visible read requests: isolation must hold for exports and reports, search, caches, background jobs, queues, webhooks, integrations, file storage and support tooling. For caches, queues, file links and background work, separately test where tenant context comes from and whether it is included in keys and access checks. Billing requires checks of rights to change plans and view invoices, tenant binding of webhooks, signatures, replay protection and idempotency; real charges are exercised only when explicitly authorised. An export or a search formally "only reads", yet can disclose more than any edit form, so reads should not automatically be treated as low-risk. And not every request that looks like a read is free of side effects: generating a report can start a heavy job or send a notification.

Chains that lead to cross-customer leakage often consist of several steps, each harmless on its own. Below is a hypothetical illustration.

1. Trial tenantThe attacker registers a free tenant and receives a legitimate role with permission to export reports.
2. ID substitutionAnother customer's object identifier is inserted into the export request; the API only checks that the user is logged in.
3. Background jobThe worker builds the file under a service account and does not verify that the object belongs to the requester's tenant.
4. File linkThe finished archive is delivered to the requester via a link, and it contains another organisation's data.

A scan with one account that does not exercise exports will not test this chain: it needs a second tenant, an understanding of the report's value and observation of the asynchronous job. Business-logic testing is therefore a substantial part of SaaS testing alongside checks that can be automated. We examined this class of checks in detail in our article on business logic security testing.

Preparing test tenants and data

A party empowered for the relevant assets and environment must explicitly authorise the use of test tenants; they are created for the engagement and populated with synthetic or minimised data. Real data is not needed: to prove a leak, it is enough to find in an export a marker row from the second test tenant. Agree in advance on roles, stubs for integrations, whether exports and mailings are allowed, and how tenants will be removed afterwards.

Which tenants, roles and integrations to include in scope is a good conversation to have with the Pentest.red team: on the pentest scoping page you can describe your tenant model, APIs and environment constraints — the depth and composition of the work depend on them.

Which standards actually help set the depth of testing

Standards are not there to be listed in a commercial proposal, but so that different providers describe the same work in the same terms and a retest is comparable with the first round.

WSTG and ASVS as a scoping language

The OWASP Web Security Testing Guide is a methodological framework for testing web applications; this article uses version 4.2 as a pinned example, while an engagement should record the version actually selected. The provider should explain which WSTG test categories were performed, which were excluded and why — for example, load-related checks may have been excluded by the rules of engagement.

OWASP ASVS solves a different problem: its stated aim is to normalise the range of coverage and rigour on the market with an open, commercially usable standard. Version 5.0.0 is used here as a pinned example. Requirement identifiers change between versions, so ASVS recommends stating the version — in a form such as v5.0.0-1.2.5. If providers map scope and findings to versioned ASVS requirements, proposals become comparable and retests become verifiable.

WSTG and ASVS address the application layer: the web application and its APIs. Cloud configuration, Kubernetes or the build pipeline need their own methods, and including them in scope is agreed separately.

The OWASP Top 10, in its 2025 edition, is an awareness document about the most critical web application risks. It is handy for explaining results to leadership and developers, but it is a list of risk categories, not a test plan. A promise only to "cover the OWASP Top 10" describes a minimum, not an assessment of a SaaS product.

Governance and product context: NIST CSF 2.0 and CISA Secure by Design

NIST SP 800-115 was published in September 2008 and replaced SP 800-42. It predates many cloud architectures, and NIST itself stresses that the document gives an overview of the key elements of technical testing rather than a ready-made programme. Its value is discipline: a formal assessment is divided into planning, execution and post-execution, the last of which includes analysing findings and developing mitigation measures. It should be combined with the OWASP material selected for the engagement and recorded by version.

The NIST Cybersecurity Framework 2.0 helps treat a pentest as one input into cyber risk management rather than a one-off event. CISA's Secure by Design initiative adds the producer's perspective: executive-level ownership of security, security by default, and MFA, logging and SSO at no extra charge. Within its agreed scope, a pentest can check how selected commitments are implemented in practice.

Which laws, standards or contracts require a pentest, and how often, is a question for your lawyers and auditors. A report can be one piece of evidence for SOC 2, ISO 27001 or PCI DSS, but it does not make a company compliant with them automatically.

Scanner, manual pentest or release-driven testing

NIST SP 800-115 treats scanning and penetration testing as different techniques, each with its own limitations. Scanning scales broad, repeatable checks, but covers business logic, multi-step scenarios and cross-tenant authorisation less well. A manual pentest can explore chains of weaknesses more deeply and safely demonstrate impact, but remains a point-in-time snapshot bounded by time, access and scope.

Black box, grey box and white box

Black box is closer to an external attacker, but a noticeable share of the budget goes on reconnaissance, and deep roles and cross-tenant transitions may never be reached. Grey box gives the team accounts, roles and API documentation. White box, with code access, can make it easier to trace a finding to its root cause and locate other instances of the same pattern, without guaranteeing an exhaustive result.

Our practical judgement: for most SaaS products a sensible starting point is grey box with the option to consult the code selectively. This is a conclusion about efficiency, not a rule: if your main threat is an attacker with no account, black box can be justified.

Cadence for a product that changes every week

SaaS changes constantly, and the results of an annual test may cease to represent the current version. CISA's guidance on secure software deployment emphasises release processes with robust testing and measurement components. One practical option is a layered model: automated checks in the pipeline, targeted tests when risky features ship — a new API, a change to the role model, a new integration — and a deeper independent pentest on a regular cadence or before major releases. We described how to bound targeted checks to the changed part of the product in our piece on change-triggered penetration testing.

Continuous and crowdsourced programmes provide broad coverage over time, but they require strong triage of incoming reports and do not replace a deliberate check of cross-tenant authorisation with prepared roles.

Running the test safely: authorisation, environment, monitoring

Written authorisation comes first. The rules of engagement record the exact scope and excluded systems, time windows, permitted techniques, data minimisation and masking, access to evidence and its retention period, stop conditions and contacts on both sides. If the product runs on cloud or service providers, check their testing policies too. Before work begins, a party empowered for each asset and environment must record the authorisation, scope and rules; the form of that record follows the engagement and applicable requirements.

Staging or production

An isolated test environment that is representative for the intended checks and filled with synthetic tenants can reduce operational risk to customers. But staging results cannot be carried over to production without caveats: configuration, feature flags, service versions, WAF settings and access permissions may differ there. So record the differences before the work starts, and have the report state on which build and in which environment each result was obtained.

If production is in scope, work is done only in dedicated test tenants, without real customer data and with an agreed request rate; denial-of-service checks are excluded unless planned separately. Mailings, payments and data deletion are agreed in advance or replaced with a safe demonstration.

Testing detection

A pentest is also useful as a test of monitoring: CISA counts logging among the features enabled by default. Compare the testers' activity log with what your systems actually recorded: did they notice identifier enumeration, cross-tenant access attempts, impersonation being switched on? If detection testing was among the agreed objectives, confirmed gaps are recorded as findings; otherwise they are reported as bounded observations.

Prioritising findings: weakness class, exploitation and blast radius

MITRE publishes the 2025 CWE Top 25 Most Dangerous Software Weaknesses and a separate list of weaknesses associated with vulnerabilities in the CISA Known Exploited Vulnerabilities catalog. Association with actually exploited vulnerabilities is a reason to examine context more closely; the priority of a specific finding should rise only when its reachability, impact, exposure and compensating controls support that decision.

But a CWE class describes a type of error and says nothing about how likely exploitation of a specific finding in your product is. A class-level KEV link is an input to analysis, not a standalone argument for priority: is the function reachable without authentication, how many tenants are affected, what data is exposed, are there compensating controls?

For SaaS, severity should gain a separate dimension — blast radius. A medium-severity defect affecting only the user's own data is very different from the same defect on the boundary between customers. The report should state explicitly whether a finding affects one user, one tenant or several. On how to combine these factors, see our article on risk-based vulnerability prioritisation.

Look for evidenced root causes rather than stopping at symptoms: analysing them can support a broader fix, while CISA Secure by Design material addresses prevention of recurring cross-site scripting, OS command injection and directory traversal at the class level. An applicable CWE identifier classifies the weakness type, while a relevant ASVS requirement links an applicable web/API check to a specific verification requirement. When evidence confirms the same cause in several places, consider correcting the shared component: centralised tenant checks on data access, safe template engines or parameterised queries.

From report to remediation and retest

Under NIST SP 800-115, an assessment includes analysing findings and developing mitigation measures. A useful report contains an executive summary, scope and methodology with applicable web/API checks mapped to WSTG and ASVS, reproducible evidence for each finding, CWE identifiers, tenant blast radius, business impact and specific recommendations. Limitations are stated separately: what was not tested, which roles and integrations were unavailable, which build the work was done on.

From there the company itself closes the loop. This is our practical scheme, not a NIST phase: agree remediation timelines by severity, assign owners, run a retest and track recurring CWE classes from one engagement to the next. Remediation can be delegated to the provider or an external team by contract, but the decision to accept residual risk belongs to an authorised risk owner in the organisation.

A retest is bounded as well: it confirms that a scenario no longer reproduces on a specific build, but does not prove the same error is absent from a neighbouring method. If a fix touches a shared component — the authorisation check, the template engine, the query builder — recheck several places where it is used. We covered how to build such verification in our article on penetration test remediation validation.

What you can show customers

CISA's Secure by Demand guide helps software customers ask vendors questions during procurement, and MITRE notes that transparency in handling weaknesses demonstrates a commitment to security. A short confirmation letter or summary with scope, dates, methodology and remediation status answers the customer without disclosing exploitation details — provided it honestly describes the limits of the test and does not present the pentest as a certificate.

Choosing a SaaS penetration testing provider

Once it is clear what to test and how the result will be used, the choice comes down to matching evidence against requirements.

What to request before the commercial proposal

Ask every shortlisted provider for the same set: a scoping questionnaire, an anonymised sample report, a description of the methodology and information about the experience of the project specialists. If the questionnaire has no questions about tenants, roles, APIs, background jobs and integrations, ask for clarification: without this information, the proposal cannot demonstrate coverage of SaaS-specific boundaries.

In the sample report, look for multi-tenant authorisation and APIs, reproducible evidence, CWE identifiers, blast radius and an approach to KEV-linked weaknesses. Clarify whether the retest is included in the price, when it happens and what it confirms, and whether there will be a customer-facing summary. Verify claims about qualifications and past clients rather than taking them on trust.

Prices are compared only after scope has been aligned: behind different prices there may be different numbers of roles, API methods and testing days. For applicable web/API checks, one verifiable way to describe scope is through versioned ASVS requirements and WSTG categories; other components need their own criteria.

Red flags

Be wary if automated scanning is presented as a pentest; if scope is fixed and ignores your tenant model; if sample reports lack reproducible evidence; if the proposal promises to "cover the OWASP Top 10" without detail; if the provider is unwilling to put authorisation and rules of engagement in writing, or promises to find "all vulnerabilities, guaranteed".

With Pentest.red you can discuss a manual pentest of a SaaS product within an agreed scope: which tenants, roles, APIs and integrations to include, what evidence the report should contain and how the retest will be organised. Terms are discussed individually via the penetration testing services page. A compliance audit, attestation or SOC 2 opinion is separate work by qualified auditors, and a pentest does not replace it.

A decision sequence for leadership

If basic security hygiene is in place and the test is expected to make a measurable contribution to risk reduction after remediation, leadership can work through this sequence in a few meetings. First, the trigger (a customer request, a major release, a new API, an architecture change, an audit): it determines whether you need a broad test or a targeted one. Then an inventory of the surface, including background jobs and tenant boundaries, and the target rigour through ASVS requirements and WSTG categories.

Next come the engagement model (grey box for depth, scanning for breadth, release-driven tests for change), written authorisation, test tenants, synthetic data, a monitoring plan and a description of the differences between staging and production. Decide in advance whether a critical cross-tenant finding blocks the release, who accepts residual risk and when the retest will happen. Prioritise results by demonstrated impact, reachability, exposure and blast radius; use CWE and class-level KEV association as context, feed them into risk management along the lines of CSF 2.0, and give customers an honest summary.

Revisit the sequence after every engagement. If findings cluster in one class, establish whether they share an evidenced cause and direct effort toward fixing it. If findings are sparse, do not infer that the product is secure: assess the remaining uncertainty, scope and access before deciding whether more testing is warranted.

What a SaaS pentest should ultimately deliver

A SaaS pentest is especially useful when its scope is built around tenant isolation, credentials and APIs, applicable web/API checks are set through WSTG and ASVS, and findings are prioritised by demonstrated exploitation conditions and blast radius and carried through to a verified fix.

Treat a pentest as a measuring instrument, not a certificate. Buy rigour you can verify, require written authorisation and reproducible evidence, record the limits of the test honestly and use evidenced root causes to correct the applicable class of defects. When confirmed fixes and lessons are built into development, the next round can start from a higher baseline, while recurring issues become a separate signal.