Penetration Testing for SaaS Platforms
SaaS penetration testing is a specialised security assessment of multi-tenancy security, data isolation, and API security on platforms where many customers share one application and one infrastructure.
It exists to prove that Tenant A cannot reach Tenant B’s objects, tokens, files, caches, or admin functions through the same live surface your customers use.
Pentesting Company delivers that assessment as an authorised, human-led engagement so you can decide whether your tenant boundaries hold before a customer, auditor, or attacker finds the gap.
This service is for technical decision-makers (CTO, Head of Engineering, Security Lead, or Product Manager) who need isolation evidence, not a generic website test.
The expected outcome is a prioritised, reproducible account of where tenant context, object-level authorisation, and API controls hold or fail, plus a fix path engineering can retest.
TEST. FIND. FIX. PROTECT. is the working sequence: isolate the attack paths that matter for a shared tenancy model, evidence them, and give engineering a fix path that can be retested.
What Is SaaS Penetration Testing and Why It Differs from Standard Web App Testing
SaaS penetration testing is a specialised security assessment that evaluates how well a multi-tenant platform enforces data isolation, secures tenant boundaries, and protects API endpoints from cross-tenant attacks.
Generic web application testing checks one application as if it served a single security domain. SaaS testing must verify that every tenant’s data stays isolated from every other tenant that shares the same code, APIs, and infrastructure.
A standard web application pentest is not sufficient for a multi-tenant SaaS platform. The tenant model creates an attack surface that generic testing does not systematically validate: tenant identifiers in requests, shared tables, shared caches, shared object storage, and tokens that must remain bound to one tenancy.
Generic Web Application Testing
Treats the app as one security domain. A scan or OWASP Top 10 review of a login form can miss an authenticated Tenant A client reading Tenant B’s records through an API the UI never exposes.
SaaS Penetration Testing
Proves tenant boundaries on a shared platform: isolation failure produces cross-tenant data leakage, IDOR, privilege escalation, and compliance breaches against personal data you process for other organisations.
APIs are usually the primary attack surface. Browser flows still matter, but tenant IDs, object IDs, JWTs, and export jobs travel over APIs. If those endpoints do not enforce tenant context on every list, get, update, delete, and report path, the UI cannot save you.
Three core pillars define the work:
- Multi-tenancy security: controls that keep identity, roles, and tenant context bound to the correct customer for every request, including workers, webhooks, and admin impersonation.
- Data isolation: proof that records, files, indexes, and derived data cannot be read or changed across tenant boundaries.
- API security: endpoint-level authorisation, object-level access checks, tenant ID handling, token validation, and abuse controls (including rate limiting) on the interfaces that actually move tenant data.
Application-layer SaaS testing should sit alongside cloud infrastructure penetration testing of the environment that hosts the platform. The SaaS provider owns tenant isolation, API authorisation, and data access controls. The cloud provider owns the underlying infrastructure controls. Mixing those layers in one generic web application test leaves the tenancy boundary unproven.
What a SaaS Penetration Test Actually Tests: Core Assessment Areas
A SaaS penetration test validates tenant isolation, session and token scope, authorisation, API object-level controls, leakage paths outside the primary database, and onboarding or offboarding residual access. Testers execute concrete actions against your tenant model rather than listing theoretical OWASP risks. Use the table to compare this scope with a generic web application test that never attempts Tenant A versus Tenant B.
| Testing Area | What We Test | Example Vulnerability |
|---|---|---|
| Tenant isolation | Authenticated as Tenant A, manipulate tenant IDs, org slugs, or account identifiers in API requests and attempt to read or change Tenant B’s data. Repeat across list, get, update, delete, and bulk operations. | Cross-tenant IDOR: object IDs from another tenant return 200 with that tenant’s records. |
| Session and token management | Confirm session cookies and JWTs are bound to the issuing tenant; attempt reuse, replay, or claim tampering across tenants, including OAuth 2.0 / OIDC token handling and refresh-token reuse. | A JWT from Tenant A is accepted on Tenant B routes because tenant claims are not enforced. |
| Authorisation controls | Attempt vertical privilege escalation inside a tenant (member to tenant admin) and horizontal access into another tenant from a low-privilege account. Include platform super-admin and support-impersonation paths where they exist. | A member role can call admin or cross-tenant endpoints by changing a path or body parameter. |
| API security | Exercise every in-scope endpoint for broken object-level authorisation, tenant ID injection, mass assignment of tenant fields, missing rate limiting, and unbounded exports. | BOLA on /invoices/{id} plus unbounded export endpoints that dump another tenant’s dataset. |
| Data leakage vectors | Probe caches, object storage, file upload and download URLs, search indexes, message payloads, and analytics pipelines for objects that are keyed without tenant context. | Search or CDN cache returns Tenant B documents to Tenant A after a crafted query or cache-key collision. |
| Tenant onboarding and offboarding | Verify that a deprovisioned tenant loses API, UI, token, and file access immediately, including invited users, service accounts, and retained integrations. | Disabled tenant still authenticates via a refresh token or retained pre-signed URL. |
| Shared schema models | Force every query path to prove tenant context is applied: list, get, update, delete, export, report, webhook, and background job. | A report query omits tenant_id and concatenates rows from multiple customers. |
Isolation is not only a database problem. A correct tenant_id filter on the primary table still fails if search indexes, caches, queues, or file keys omit tenant context.
Testers need at least two tenants with comparable objects so those substitutions have a real target.
If a provider cannot describe these actions in Tenant A versus Tenant B terms, they are offering a standard application test with SaaS language attached. Ask for evidence of isolation testing, not only XSS or SQL injection on a login form.
How Data Isolation Models Shape Your Testing Approach
Database-per-tenant, schema-per-tenant, and shared schema each change where a tester hunts for isolation failure, and none of them is inherently secure or insecure.
Security depends on implementation quality: connection handling, query filters, row-level controls, and every secondary store that copies tenant data. Identify your model first so the engagement spends time on the failure modes that actually apply.
A shared schema is not automatically unsafe; it is the model that punishes a missing tenant predicate the hardest.
| Isolation Model | Security Strengths | Security Risks | Testing Focus |
|---|---|---|---|
| Database-per-tenant | Strongest physical separation of data stores; a missed WHERE clause cannot easily join another customer’s tables. | Mis-routed connections, shared admin credentials, backup or snapshot exposure, and jobs that attach the wrong database. | Cross-database access, connection-string mix-ups, restore and backup exposure, and shared services that still sit in front of all databases. |
| Schema-per-tenant | Logical separation inside one database engine, with a clearer blast radius than a single shared table set. | Over-privileged database roles, cross-schema queries, and search or reporting users that can see every schema. | Schema-level access controls, search_path abuse, cross-schema SQL, and tooling that enumerates other tenants’ schemas. |
| Shared schema | Operationally dense; isolation lives in application tenant context and row-level security rather than in separate stores. | Any missing tenant predicate, unsafe default, or background worker without context becomes a cross-tenant read or write. | Tenant-context management, row-level security, IDOR on every object type, and every query path including exports, search, and async jobs. |
Shared schema models require more rigorous tenant-context testing than database-per-tenant. Hybrids (for example dedicated databases for enterprise tenants and a shared schema for everyone else) need both connection-routing tests and row-level tests.
A provider who treats all three models as a single IDOR check will under-test the model you actually run. Tell the tester which model you use, including hybrids, before scoping days are agreed.
Black-Box vs. Grey-Box vs. White-Box Testing for Multi-Tenant SaaS
Grey-box testing is the recommended default for multi-tenant SaaS because the tester needs architectural context to exercise tenant isolation, while black-box and white-box sit at the extremes of knowledge and depth.
Methodology is a scoping choice, not a badge. Choose it based on whether the tester must understand your tenant model to prove isolation, not based on which label sounds most aggressive.
| Methodology | What the Tester Receives | Strengths | Limitations | Best For |
|---|---|---|---|---|
| Black-box | No internal knowledge beyond a URL, credentials, and public behaviour. | Closest simulation of an uninformed external attacker. | May miss isolation bugs that only appear when the tenant model, shared tables, or internal IDs are understood. | External attacker simulation as a supplement, not as the sole isolation proof. |
| Grey-box | Partial knowledge: architecture notes, tenant model, API documentation, and representative tenant accounts. | Balances attacker realism with enough context to target tenancy systematically. | Does not replace a full source-assisted review of every code path. | Most multi-tenant SaaS platforms that need isolation evidence in a bounded window. |
| White-box | Source code plus architecture, often with deeper environment access. | Deepest inspection of tenant filters, middleware, and hidden endpoints. | Most resource-intensive; wider code access and longer analysis time. | High-assurance reviews, complex shared-schema codebases, or regulated platforms that need code-path evidence. |
Black-box testing alone may miss issues that require understanding of the tenant model, such as a background worker that drops tenant context or an internal ID format the UI never shows.
Grey-box is the sensible baseline because it gives the tester the tenant model, API contracts, and two tenant accounts without turning the engagement into a full code audit.
Ask for grey-box as the baseline, then add white-box on the isolation-critical services if your risk or customer contracts demand it.
The SaaS Penetration Testing Process: From Scoping to Report
A SaaS penetration test runs from a scoping call through preparation, 1–3 weeks of testing, analysis, remediation support, and retesting. You should know what to provide, who must be on call, and where testing runs before work starts.
The shared responsibility model sets the boundary: this engagement covers application-layer tenancy, APIs, and data access controls. Infrastructure controls owned by AWS, Azure, or GCP sit outside that application scope unless they are commissioned separately as cloud infrastructure testing.
- Scoping call. Define testing boundaries, identify the tenant model, agree black-box, grey-box, or white-box, and confirm staging versus production. List applications, API groups, roles, and out-of-scope third parties. Agree how deep verification should go (for example mapping coverage to OWASP ASVS-style controls for access control and API authorisation) so days are spent on tenancy, not on an unbounded hunt.
- Preparation. Supply architecture documentation, API documentation, at least two tenant accounts, and a named technical point of contact. Confirm log owners, because cross-tenant attempts will create noise.
- Testing execution. Conduct the assessment, typically over 1–3 weeks depending on endpoint count, isolation model, and methodology. Testers work through isolation, tokens, authorisation, APIs, leakage stores, and offboarding, not a single automated scan.
- Analysis and reporting. Prioritise findings by severity, retain evidence for each issue, and write a report that engineering can reproduce.
- Remediation support. Deliver the report with fix guidance mapped to your architecture, so developers are not left with a vulnerability name and no tenant-context advice.
- Retesting. Re-run the proven attack paths after fixes land and confirm the isolation failure is closed.
Testing should run in a staging environment that mirrors production where possible.
Production testing is only appropriate with scheduling, monitoring, and an operations contact, because tenant-isolation attempts can trip WAF rules, audit alerts, and rate limiters. Coordinate those alerts in advance rather than discovering them mid-test.
Isolation proofs generate log noise; they should not generate an incident for paying customers.
What Affects the Scope, Cost, and Timeline of a SaaS Penetration Test
Scope, cost, and timeline of a SaaS penetration test move with tenant-model complexity, API and application surface, role design, architecture style, methodology, and whether retesting is included.
A simple SaaS with one API and a shared schema will take less time than a platform with many services, microservices, hybrid isolation, and several product UIs. Providers quote different shapes of work because those variables change the number of tenant-context paths that must be proven, not because SaaS is a single product type.
- Number of applications and API endpoints. Each extra product surface and object type adds isolation cases (list, get, update, delete, export).
- Complexity of the tenant model. Shared schema needs more tenant-context testing than database-per-tenant; hybrids need both connection-routing tests and row-level tests.
- Number of user roles and permission levels. More roles means more vertical and horizontal escalation paths inside and across tenants, including support impersonation.
- Microservices versus a monolith. Distributed services multiply tenant-context hand-offs between gateways, workers, and data stores.
- Testing methodology. Black-box, grey-box, and white-box change preparation, access, and analysis time.
- Web applications, APIs, and mobile backends. Extra clients often share APIs but introduce different token storage and deep-link IDOR paths.
- Remediation retesting. A second pass to validate fixes adds time; omitting it leaves the engagement as an unclosed finding list.
Bring an inventory of products, endpoint groups, roles, and isolation model to the scoping call. That briefing is what makes a quote comparable. Exact fees belong in a written quote against your inventory, not in a generic range on a service page.
How to Prepare for a SaaS Penetration Test
To prepare for a SaaS penetration test, gather architecture and API documentation, provide a staging environment that mirrors production, issue at least two tenant test accounts, and name a technical point of contact.
Test quality tracks the quality of that context. A tester who cannot see the tenant model cannot prove isolation with any reliability. Withholding architecture to stay realistic usually produces a shallower test, not a more honest one.
- Architecture documentation: tenant model, isolation approach, and data-flow diagrams covering databases, caches, files, search, and jobs.
- API documentation: endpoints, authentication (including OAuth 2.0 / OIDC and JWT claims), and object schemas that carry tenant identifiers.
- Test environment access: staging that mirrors production, or a production window with monitoring if staging cannot represent tenancy.
- Tenant accounts: at minimum two tenants, with comparable objects so isolation tests have a real target on both sides.
- Technical point of contact: someone who can confirm how tenant context is set on requests, workers, and reports during the test window.
- Operations coordination: agree how log noise, WAF blocks, and alerting will be handled so isolation tests are not mistaken for an incident.
- Remediation calendar: reserve engineering time after delivery for triage, fixes, and retesting rather than parking the report.
If staging diverges from production tenancy (different row-level policies, missing search indexes, or dummy tokens), say so in scoping. The tester then either adjusts technique or schedules a controlled production pass for the paths staging cannot represent.
What Happens After the Test: Findings, Remediation, and Retesting
After a SaaS penetration test, findings are reported by severity with evidence and architecture-specific remediation guidance, then retested once engineering applies fixes.
The engagement is not complete when a PDF lands. Value is a closed isolation failure, not a list of issue titles.
Plan internal capacity for triage in the same sprint window you booked the test; unused reports do not satisfy customers or auditors.
A typical report contains:
- An executive summary for non-technical stakeholders
- Detailed technical findings for engineering
- Evidence for every issue: screenshots plus request and response pairs that show the tenant boundary breaking
Findings are prioritised as critical, high, medium, or low so you can sequence work that stops cross-tenant reads before cosmetic hardening.
Remediation guidance should be actionable against your model:
- Tenant-context middleware
- Object-level checks
- Token claims
- Cache keys
- Offboarding token revocation
Generic advice to implement access control wastes sprint time.
After fixes, retesting repeats the original proof so you do not declare IDOR closed on a single object type while exports still leak.
Include retesting in the engagement rather than treating it as an optional extra you may never buy.
Penetration testing reduces uncertainty about tenant boundaries; it does not remove the need for secure development, monitoring, or a later retest after the next isolation change.
Compliance and UK GDPR Considerations for SaaS Security Testing
UK GDPR requires appropriate technical and organisational measures to protect personal data, and penetration testing is a recognised way to show those measures have been tested.
For a multi-tenant SaaS platform, that evidence must speak to isolation, not only to perimeter scanning. The Information Commissioner’s Office expects data controllers to test security controls rather than assume them.
Many SaaS businesses also act as processors for customer personal data; enterprise customers still ask you for testing evidence because their controller duties depend on your isolation holding.
A penetration test report gives auditors documented proof that tenant boundaries, API authorisation, and access controls were attacked and either held or were remediated. That is the artefact procurement, enterprise customers, and security questionnaires actually ask for.
Other frameworks commonly demand comparable testing evidence:
- SOC 2: control operation over the audit window, including how customer data is restricted in a shared service.
- ISO 27001: risk treatment and technical control verification, including access control and secure development evidence.
- PCI-DSS: where card data is in scope, defined testing of applications and segmentation that a multi-tenant design can undermine if isolation fails.
Do not treat a pentest report as a certification. It is evidence that controls were tested on a stated date against a stated scope. Keep that scope honest: if shared-schema isolation was not tested, do not present the report as proof that it was.
How Often Should You Penetration Test a SaaS Platform?
SaaS platforms should be penetration tested at least annually, with extra tests after major architectural, feature, or tenant-model changes. Frequency should match risk and rate of change, not a single calendar ritual.
Platforms that ship weekly into a shared schema accumulate new query paths faster than an annual test can cover on its own.
Use annual testing as the baseline for every SaaS product that stores customer data. Add a focused test when you change isolation (for example moving toward shared schema), introduce a new product API, redesign roles, or open a new data residency path.
High-risk platforms in fintech, healthtech, or enterprise-tenant estates should plan quarterly or continuous assessment so isolation regressions are found inside the same quarter they ship.
Trigger events that should not wait for the anniversary:
- New isolation model or hybrid tenancy.
- Major feature releases that add objects, exports, search, or admin impersonation.
- Significant changes to authentication, JWT claims, or tenant context middleware.
- Onboarding a class of tenants with a higher data-sensitivity contract.
- Material microservice splits that pass tenant context across new boundaries.
Questions to Ask a Potential SaaS Penetration Testing Provider
Ask a potential SaaS penetration testing provider about multi-tenant experience, isolation models they have tested, methodology, remediation, retesting, and team qualifications such as CREST.
A generic web application tester who has never proved shared-schema isolation will not discover it from a scanner output.
Use the answers to shortlist, then judge whether they can explain how they would test your model in Tenant A versus Tenant B terms.
- Have you tested multi-tenant SaaS platforms before?
- What isolation models have you worked with (database-per-tenant, schema-per-tenant, shared schema)?
- What methodology do you use (black-box, grey-box, white-box), and why for our tenancy design?
- Do you provide remediation guidance with your findings, mapped to architecture rather than generic advice?
- Is retesting included in the engagement?
- What qualifications and accreditations does your testing team hold (for example CREST)?
- Can you provide case studies or references from SaaS clients?
- How do you handle testing in production without disrupting service, including log noise and monitoring?
Look for a provider who can describe Tenant A versus Tenant B test cases for your isolation model in the scoping call, including caches, files, and async jobs rather than only the primary CRUD API. If they cannot, keep looking.
Frequently Asked Questions
These FAQs give direct answers on multi-tenancy security, data isolation, IDOR, test duration, and testing cadence for SaaS platforms.
What is multi-tenancy security?
Multi-tenancy security is the set of controls that keep each SaaS customer’s data and actions confined to their own tenant when many customers share one application and infrastructure. The core requirement is that a user or API client from Tenant A cannot read, change, or infer Tenant B’s resources. Penetration testing proves those controls under attack rather than on a design diagram.
What is data isolation in SaaS?
Data isolation in SaaS is the enforced separation of each tenant’s data from every other tenant, including databases, caches, files, search indexes, and analytics. Common models are database-per-tenant, schema-per-tenant, and shared schema with tenant-scoped controls. Each model has different testing implications, and each is only as strong as the implementation a tester can break or fail to break.
How is a SaaS penetration test different from a standard web application test?
A SaaS penetration test systematically verifies tenant boundaries on a shared platform, while a standard web application test assesses one application without proving isolation between customers. SaaS testing adds tenant ID manipulation, cross-tenant token reuse, shared-schema query paths, and offboarding residual access. SQL injection and XSS still matter, but they do not answer the tenancy question on their own.
What is IDOR and how does it affect multi-tenant SaaS?
IDOR (Insecure Direct Object Reference) is an authorisation flaw where changing an object identifier grants access to another user’s or tenant’s record. In multi-tenant SaaS it is the usual path to cross-tenant reads and writes on invoices, files, users, and exports. Testers authenticate as Tenant A and substitute Tenant B identifiers until the API accepts or correctly refuses the request.
How long does a SaaS penetration test take?
A SaaS penetration test typically takes 1–3 weeks of execution, depending on API surface, tenant model, role set, and methodology. Shared schema and microservice estates sit toward the longer end because every query path needs tenant-context proof. Scoping, reporting, and retesting sit around that testing window rather than inside it.
How often should a SaaS platform be penetration tested?
A SaaS platform should be penetration tested at least once per year, and again after major architectural, feature, or tenant-model changes. High-risk products handling sensitive data should consider quarterly or continuous testing. Match cadence to how fast you ship new object types and tenancy logic, not to a single annual certificate date.
Discuss a SaaS Penetration Testing Engagement
A scoping conversation is the correct next step once you know your isolation model, API surface, and whether grey-box access can be provided. Bring architecture notes, a count of in-scope applications and endpoints, and any compliance deadline (UK GDPR evidence, SOC 2, ISO 27001, or customer questionnaire).
Pentesting Company will use that briefing to define boundaries, environment, and testing depth without treating your platform as a generic website.
Contact Pentesting Company via pentestingcompany.co.uk to request a quote or book a scoping call.
State that you need SaaS multi-tenancy, data isolation, and API security testing so the conversation starts on tenant boundaries, not a standard web form review.