Penetration Testing for SaaS Companies
Why annual testing is no longer enough for multi‑tenant, API‑driven products
SaaS companies operate differently to traditional software vendors. Their products are multi‑tenant, API‑first, deployed continuously and exposed to the internet by design. Attackers know that a single weakness can expose data for thousands of customer organisations. Meanwhile, enterprise buyers require proof of security assurance — penetration tests, SOC 2 reports, ISO 27001 certifications — before signing contracts.
Annual application tests are therefore insufficient. SaaS providers need ongoing testing across their applications, APIs, cloud infrastructure and identity systems. This article explains why SaaS targets attract attention, what to test in priority order and how often, where multi‑tenant boundaries fail, and what evidence customers expect.
Why SaaS organisations attract attention
SaaS providers are attractive targets for several structural reasons:
- Concentration of data: One SaaS platform may store confidential information for thousands of customers. An attacker who crosses a tenant boundary gains access to multiple organisations.
- Large public attack surface: The application, API, marketing site, support portal and admin tooling are all internet‑facing.
- Integration complexity: SaaS relies on OAuth grants, webhooks, third‑party APIs and identity providers; each trust relationship can be abused.
- Rapid change: Continuous deployment means code and configuration change daily. Indusface's analysis found that API attacks increased by 104 % year‑on‑year, with 13 times more vulnerability exploits against APIs than websites.
- Customer expectation: Enterprise customers demand evidence of security assurance — penetration test summary letters, SOC 2 Type II reports, ISO 27001 certifications — before signing.
These factors mean that a single annual test misses most of the risk. The product evolves, new integrations appear and threat actors target multi‑tenant weaknesses. SaaS security assurance must be continuous and multi‑layered.
What to test, in priority order
An effective SaaS penetration testing programme covers five surfaces, roughly in this order:
1. Application and API
The core product must be tested end‑to‑end. Indusface highlights that SaaS is API‑first: APIs power integrations and are prime targets for attackers. Testing should go beyond the OWASP API Top 10 to include discovery of undocumented or "shadow" APIs, object‑level and function‑level authorisation checks, data exposure, mass assignment and rate‑limiting issues.
2. Multi‑tenant boundaries
Tenant isolation failures are the most damaging SaaS weaknesses. Misconfigured access control or weak privilege enforcement allows one tenant to access another's data. Proper testing attempts cross‑tenant data access via APIs and dashboards, validates that session tokens cannot be reused across tenants and verifies role‑based access controls at scale. This testing requires manual creativity; automation alone will not uncover subtle cross‑tenant bugs.
3. Cloud configuration
Misconfigured cloud accounts can expose secrets and data even when the application itself is secure. Review identity and access management policies, public storage settings, exposed services, network segmentation, secrets management and logging configuration. This area often requires separate cloud‑configuration reviews aligned with CIS Benchmarks.
4. Identity infrastructure
SaaS platforms depend on federated identity (SSO, OAuth, SAML). Penetration tests should simulate credential stuffing, token theft and multi‑factor bypass, validating MFA enforcement, session expiry and secure token handling. Testing should cover misconfigurations in SAML, OAuth and OpenID Connect flows.
5. External infrastructure
Marketing sites, status pages, support portals and documentation sites are part of your attack surface. A compromised marketing CMS can deliver malicious JavaScript to users. These assets require regular assessment.
The multi-tenancy problem specifically
Multi‑tenant isolation is consistently under‑tested but has the most severe consequences. Indusface notes that SaaS platforms are built on shared infrastructure and that misconfigured access control or poor tenant isolation can allow one customer to access another's data. Because multi‑tenant boundaries vary by implementation (row‑level filtering, per‑tenant schemas, per‑tenant databases or separate cloud accounts), testers must design explicit scenarios to probe them.
A thorough multi‑tenancy test should:
- Probe cross‑tenant authorisation (BOLA/BFLA): Manipulate identifiers to see whether a user in tenant A can read, modify or delete resources in tenant B.
- Check tenant context in background processes: Assess whether background jobs, scheduled tasks, admin actions or webhooks enforce tenant context.
- Identify shared infrastructure leakage: Examine caches, queues, search indexes and logging pipelines for cross‑tenant data exposure.
- Validate tenant admin boundaries: Ensure tenant administrators cannot elevate privileges to global or system‑wide scope.
- Verify audit log isolation: Confirm that audit logs are tenant‑scoped so one tenant cannot view another's audit events.
General application testing will not automatically cover these scenarios. Multi‑tenant testing must be explicitly scoped and designed. For most SaaS organisations, annual multi‑tenant assessments are a minimum; additional tests should follow significant changes to tenant isolation logic.
Testing cadence that works for SaaS
A typical cadence for a mid‑stage SaaS provider looks like this:
- Quarterly application and API testing: or per major release, whichever is more frequent. Incorporate manual business‑logic and multi‑tenant tests.
- Annual cloud configuration review: covering IAM, networking, storage, logging and secrets management.
- Annual identity infrastructure review: covering SSO, OAuth/SAML/OpenID Connect, MFA enforcement, session management and account recovery.
- Annual external infrastructure test: covering marketing sites, status pages and support portals.
- Continuous external attack surface monitoring: to catch newly exposed services, subdomains or certificate issues.
- Continuous vulnerability scanning: to maintain hygiene on dependencies and infrastructure layers.
- Pre‑launch testing for sensitive changes: any feature affecting authentication, authorisation, payment, customer data export or third‑party integration warrants targeted testing before release.
Customer‑mandated tests are common in enterprise sales. A well‑run programme treats these requests as routine rather than disruptive by maintaining documentation, NDA templates and scheduling guidelines.
Evidence enterprise customers expect
Demonstrating that testing was meaningful is as important as performing it. Enterprise customers typically request:
- Penetration test summary letters: Redacted reports from a CREST‑certified or NCSC CHECK‑aligned provider, released under NDA.
- SOC 2 Type II report: Evidence that security testing is part of the control narrative.
- ISO 27001 certification: Annex A 8.8 requires that vulnerabilities are identified and treated on a defined cadence.
- Remediation evidence: Customers increasingly ask what you found and what you fixed, not just whether testing occurred. Be ready to discuss remediation in general terms.
Frequently asked questions
Do we need a pen test before SOC 2?
You typically need penetration testing for SOC 2 Type II if your selected control set references it, which most do. Auditors look for evidence that testing occurred at a defined cadence and that findings were tracked through to remediation.
Should we test our staging or production environment?
Production is preferred for accuracy. A representative staging environment with the same configuration as production is acceptable; a dev environment with skeleton data is not.
How should we handle customer-mandated pen tests?
Customer-mandated testing is increasingly common in enterprise B2B sales. Maintain a documented process for granting scoped access under NDA, with clear timing and reporting expectations. Treat it as a sales-enabling control.
Is application security testing the same as SaaS pen testing?
Overlapping but not identical. SaaS testing must specifically cover multi-tenancy, cloud configuration and identity infrastructure — areas a generic application test will often miss.