pentest · saas

Penetration testing for SaaS companies.

Multi-tenant applications where a single broken authorization check exposes every customer's data. Enterprise buyers verify your SOC 2. We scope SaaS engagements around what matters: tenant isolation, API security, the authentication chain, and the compliance evidence your auditor will accept.

01. attack surface

What attackers target in SaaS.

The SaaS attack surface is different from a traditional web app. Tenant isolation and API authorization are the critical surfaces — not just the login page.

Tenant isolation failures

Broken object-level authorization and IDOR flaws that let one customer read, modify, or delete another's data. The most common critical finding in SaaS pentests. Affects APIs, background jobs, file storage, and cached query results.

API authorization gaps

Broken function-level authorization, mass assignment, and missing ownership checks on REST and GraphQL endpoints. Internal service-to-service APIs are frequently undertested and overtrusted.

Authentication bypass

SSO misconfigurations, OAuth2 redirect_uri manipulation, SAML signature wrapping, JWT algorithm confusion, SCIM provisioning abuse. Enterprise SSO is complex and the attack surface grows with each IdP integration.

Subscription tier escalation

Business logic flaws that let users access features, storage, seats, or API rate limits above their paid tier. Often exploitable through parameter manipulation or by directly calling plan-gated API endpoints.

Integration and webhook abuse

SSRF through third-party integration endpoints, unsigned or weakly signed webhook delivery, credential leakage in incoming event payloads, and replay attacks against idempotency keys.

CI/CD and secrets exposure

Hardcoded API keys in git history, overly permissive GitHub Actions workflows, deployment credentials with excessive blast radius, and publicly accessible build artifacts.

02. scope

What we test in a SaaS pentest.

A SaaS engagement covers more than the web app. Scope is agreed on the scoping call and documented in the SOW.

Multi-tenant data layer

Cross-tenant access checks across every API endpoint, database query path, file storage access, background job queue, and caching layer. We test with multiple tenant accounts simultaneously.

Authentication and SSO

SAML, OIDC/OAuth2, SCIM provisioning, session management, password reset flows, and MFA bypass. Every authentication path your customers use.

REST and GraphQL APIs

All endpoints your customers call, plus internal service-to-service calls if in scope. OWASP API Top 10 aligned. GraphQL introspection, batching abuse, and field-level authorization.

Admin and operator consoles

Internal tooling with elevated access is frequently undertested and underdocumented. Access to admin endpoints from a compromised customer account is a common lateral-movement path.

Webhooks and integrations

Signature verification, replay protection, SSRF risk through callback URLs, and credential handling in integration configuration flows.

Cloud infrastructure

S3 bucket permissions, IAM misconfigurations, metadata-service access via SSRF, Lambda function permissions, cross-account access paths. Optional add-on to the application test.

03. compliance

Compliance your enterprise customers actually verify.

SaaS companies face security questionnaires from every enterprise deal. The pentest report is the evidence behind multiple controls.

  1. SOC 2 Type I and IIMost enterprise SaaS buyers require it. Trust Services Criteria CC6.1 (logical access), CC6.6 (external transmission), CC7.1 (anomaly detection), and CC8.1 (change management) all reference security testing as supporting evidence. We deliver the report format auditors accept in 2026: named engineer, CVSS 4.0 severity, retest section, attestation letter. SOC 2 pentest details →
  2. ISO/IEC 27001:2022Required by European enterprise buyers and for government-adjacent contracts. Annex A.8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance) require evidence of periodic technical security testing. Our report maps to both controls.
  3. HIPAA (if applicable)If your SaaS handles any protected health information — even indirectly as a Business Associate — §164.308(a)(8) requires periodic technical evaluation. We execute a BAA before testing. HIPAA pentest details →
  4. PCI DSS v4.0 (if applicable)If your platform processes, transmits, or stores cardholder data, Requirement 11.3.1 and 11.3.2 require internal and external penetration testing of the CDE annually. PCI DSS pentest details →
04. deliverables

What you walk away with.

Everything your engineering team needs to fix findings, and everything your auditor needs to close the control.

Tenant isolation test matrix

Every cross-tenant access check documented with test case, endpoint, tenant pair used, and result. Pass or fail with evidence. Shows auditors and customers exactly what was covered.

Findings report

Executive summary, full finding catalog with CVSS 4.0 severity, exploit chain, working PoC, business impact, and remediation steps. 15–60 pages depending on scope. Markdown on request.

Retest within 30 days

Same engineer re-validates every remediated finding. Each marked resolved, partially resolved, or open with notes. Retest report issued separately for auditor evidence.

SOC 2 attestation letter

Signed by the engineer who ran the test. States scope (cross-referenced to your system description), methodology, dates, engineer name, and retest outcome. One page. Attaches to the control in your auditor's evidence package.

Engineer readout

60–90 minute live walkthrough with your engineering team. Walk every finding, agree remediation order, answer architecture questions before the call ends.

Working PoCs

Every finding comes with reproducible exploit code or a step-by-step walkthrough. Your engineers verify every claim before triage. No "trust us" findings.

05. faq

Questions before the call.

How long does a SaaS penetration test take?

Most SaaS web-app and API engagements run two to three weeks of active testing, plus a week for the report and readout. Add a second API surface or mobile app and budget another week. We scope precisely on the call.

Can you test in production?

For read-only checks, yes. For anything that could modify or delete customer data, we agree a production-like staging environment with realistic data before testing starts. The line is set in the SOW in writing.

Do you need source code access?

Gray-box is the default: no source code, but some architectural context and test credentials. White-box with source code finds more in the same budget. Black-box on request.

We have a bug bounty program — do we still need a pentest?

Bug bounties find what motivated strangers discover in their spare time with limited scope. A pentest finds what a senior engineer finds in three focused weeks with full scope access. SOC 2 auditors do not accept bug bounty reports as pentest evidence.

Can the report satisfy both SOC 2 and ISO 27001?

Yes. A well-scoped report with named methodology, CVSS 4.0 severity, and a retest section satisfies SOC 2 Trust Services Criteria and ISO 27001 Annex A.8.8 and A.8.29. We include an attestation letter formatted for both auditor evidence packages.

Ready to scope a SaaS pentest?

30-minute scoping call covers your app surface, your audit deadline, and the scope your auditor expects. Free.