For a SaaS company, the product is the attack surface. There is no on-premise deployment to hide behind, no air gap, no customer-managed perimeter. Your application sits on the internet, holds many customers’ data at once, and changes every sprint. That combination makes penetration testing not a compliance checkbox but a core part of running the business responsibly.
What makes SaaS different to test
A few characteristics shape how a SaaS platform should be assessed:
- Multi-tenancy. Many customers share the same application and often the same database, separated by logic rather than physical boundaries. The defining SaaS risk is tenant isolation failure: one customer reaching another’s data. It is also invisible to scanners, because the request that leaks tenant B’s data is a perfectly valid one, just made by tenant A.
- Continuous deployment. Code ships weekly or daily. An annual test captures one moment in a fast-moving target, which is why testing cadence and coverage matter more here than almost anywhere. The pipeline that ships the code is a target in its own right, covered in our guide to CI/CD pipeline security.
- Rich role and permission models. SaaS products layer roles, organizations, and granular permissions. Every one of those boundaries is a place where authorization can break.
- Deep integrations. APIs, webhooks, OAuth connections, and third-party services extend the surface well beyond the main UI. If your product is built on Salesforce or sold on AppExchange, Salesforce penetration testing covers that platform, including prep for the AppExchange security review, and our guide to the Salesforce AppExchange security review explains what Salesforce checks.
- Enterprise buyers who demand proof. Your customers’ security teams will ask for a recent penetration test report before they sign, and many will expect SOC 2 evidence alongside it. Testing is not only defense; it is a sales enabler.
The risks that matter most
In SaaS engagements, the highest-impact findings cluster around a few themes:
- Tenant isolation. Can one customer access another’s data by manipulating IDs, tokens, or requests? This is the finding that ends SaaS companies, and proving it requires testing with multiple tenant accounts, not just one.
- Authorization within a tenant. Can a low-privilege user reach admin functions, or a member of one organization act on another’s resources? Complex role models fail in subtle ways.
- API security. SaaS runs on APIs, and they are frequently less guarded than the UI. Broken object-level authorization is the recurring culprit.
- Account and session management. Weaknesses in authentication, password reset, session handling, or SSO integration, all high-value because they gate everything else.
- Business logic abuse. Subscription limits, usage quotas, and workflow rules enforced client-side or trusted too readily on the server.
Multi-tenant test cases
Tenant isolation is not one test. It is a set of test cases, each run as tenant A trying to reach tenant B. These are the ones every SaaS engagement should include:
| Test case | What the tester tries | What a failure looks like |
|---|---|---|
| Object IDs across tenants | Swapping record, file and user IDs in requests made from tenant A | Tenant A reads or changes tenant B’s records |
| Organization switching | Changing the workspace or organization ID in the session, URL or API call | A user acts inside an organization they never joined |
| Invitation flows | Reusing, forging or replaying invites, and changing the role inside an invite | An outsider joins a tenant, or a member joins as admin |
| SSO and SAML | Tampered assertions, unsigned responses, and one tenant’s identity provider logging into another tenant | One customer’s IdP grants access to another customer’s data |
| Per-tenant API keys | Calling another tenant’s resources with a valid key, and testing scopes on integration tokens | A key issued to tenant A works on tenant B |
| Exports and reports | Running exports, reports and search with filters removed or changed | A CSV or report that includes other tenants’ rows |
| Background jobs and webhooks | Triggering jobs and webhooks that carry tenant context | Tenant B’s data delivered to tenant A’s endpoint |
Proving any of these needs at least two tenants, with an administrator and a member in each. A scanner cannot run them, because every request in the table is a valid one.
Scoping a SaaS pentest
To get real value, a SaaS engagement needs to be scoped with isolation and roles in mind. When you scope a test, plan to provide:
- Multiple accounts across multiple tenants. Proving tenant A cannot reach tenant B’s data requires a real tenant B. This is the single most important detail, and the one teams most often forget.
- Accounts at every privilege level, so vertical authorization can be tested end to end.
- API documentation (OpenAPI, GraphQL schema, or a Postman collection) alongside the web interface.
- A staging environment that mirrors production, so testing is thorough without risking live customer data.
Cadence: annual is a floor, not a ceiling
Because SaaS ships continuously, an annual test is the minimum, and rarely enough on its own. Our guide on how often to run a penetration test covers the framework minimums. A more resilient rhythm:
- A comprehensive web application penetration test at least annually, and ideally with a retest included so your report shows verified fixes
- Focused testing around major feature releases, especially anything touching authentication, authorization, or the tenancy model
- Ongoing visibility into your external surface between engagements
Enterprise security reviews and SOC 2
Most SaaS companies commission their first test for one of two readers: an enterprise prospect’s security team, or a SOC 2 auditor. Buyers in Europe often ask for ISO 27001 instead, and our comparison of ISO 27001 vs SOC 2 covers which report each buyer expects. Both want the same things from the report. The scope matches the product they are buying or the system you described to the auditor. The test is recent. The findings show severity and whether they were fixed, with a retest to prove it.
The difference is what each reader keeps. The auditor files the full report against the criteria it evidences. A prospect usually needs only an attestation letter: a signed one-page summary of scope, dates, methodology and outcome, with no technical detail. Our SOC 2 pentest requirements guide covers how to time the test inside the audit window so one engagement serves both.
What SaaS penetration testing costs
A SaaS scope is built from the published prices of the tests it contains. There is no SaaS surcharge.
| Test | Covers | Starts at |
|---|---|---|
| Web application | The product and every role, across at least two tenants | $5,200 |
| API | The endpoints behind the product and the integrations customers connect to | $4,000 |
| Cloud | The AWS, Azure or GCP account that hosts the product | $6,800 |
Each price is fixed in writing before work begins, and each includes a free retest of remediated findings. Most first SaaS engagements are the web application test plus the API test. Products that run on Kubernetes can add a Kubernetes penetration test of the cluster, from $6,800, to check whether a compromised pod reaches other tenants or the cloud account behind it. Products with many roles, tenants or endpoints move up the published tiers. The price calculator adds up the tests in your scope.
The payoff
Done well, SaaS penetration testing protects the two things your business runs on at once: your customers’ data and your customers’ trust. A clean, recent report shortens enterprise security reviews and unblocks deals, while the testing itself catches the isolation and authorization flaws that would otherwise become a breach affecting every customer at once. For a SaaS company, that is not overhead. It is the cost of being trusted with other people’s data, and it pays for itself the first time it keeps you out of the headlines.
Frequently asked questions
How often should a fast-moving SaaS company run a pentest? At least once a year, inside each SOC 2 audit period, and again when the authorization model changes: a new role, SSO, a public API, or an integration marketplace. Teams that ship those changes monthly usually move to scheduled test windows with validated scanning in between.
Do we need to create test tenants? Yes. Provide at least two tenants, with an administrator and a member account in each. Without a second tenant, nobody can prove that tenant A cannot reach tenant B, which is the finding that matters most.
Should we test production or staging? Staging, where it mirrors production, so testing is thorough without touching live customer data. Where no staging environment exists, production testing runs under written rules of engagement: agreed windows, test tenants only, and no destructive actions.
Our product has AI features. Are they covered? The web application and API around them are. The model-specific risks, such as prompt injection, data leakage through the model and unsafe tool use, need AI and ML penetration testing added to the scope.
Can we share the results with prospects? Yes, through the attestation letter. The full report stays with you, your engineers and your auditor.
Evaluating a test rather than reading up? The SaaS penetration testing services page covers what we test and the fixed starting prices, and our SaaS industry page covers which frameworks apply.
Because SaaS ships continuously, many teams move from annual testing to penetration testing as a service or a continuous penetration testing program, which tracks release cycles instead of the calendar. Our PTaaS program shows what a SaaS program year looks like. Scope your engagement around your tenancy and role model, and test the boundaries that matter most.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →