How Do You Scope a Penetration Test for a Multi Tenant SaaS Platform?

A multi tenant SaaS platform serves multiple customers through a shared application environment.

That architecture creates a critical security question:

Can one customer access another customer's data, functionality or resources?

A penetration test for a multi tenant SaaS platform should therefore go beyond checking common application vulnerabilities.

The scope needs to validate how tenant isolation, APIs, authentication, authorization, user roles and business workflows behave when a legitimate user attempts to access something outside their permitted tenant.

For SaaS companies preparing for enterprise onboarding, getting this scope right can be the difference between a useful security assessment and a report that leaves important risks untested.

A conventional web application may primarily need to protect users and their permissions.

A multi tenant SaaS platform has another security boundary:

Tenant A must not be able to access Tenant B.

This boundary can exist across:
• Web applications
• APIs
• Databases
• File storage
• Background processes
• Administrative functions
• Integrations

A vulnerability in tenant isolation can potentially expose customer data across organizations.

This makes tenant isolation a specific requirement that should be explicitly considered during SaaS penetration testing.

The scope should reflect the actual SaaS attack surface.

Depending on the platform, it may include:
• Customer facing web application
• APIs
• Administrative portal
• Authentication system
• User roles
• Tenant management
• File upload and download functionality
• Business critical workflows
• Third party integrations
• Cloud infrastructure where applicable

The scope should also identify which environments are authorized for testing and which assets are excluded.

A clear scope prevents the assessment from becoming a generic vulnerability scan.

Tenant isolation testing should determine whether controls consistently prevent unauthorized cross tenant access.

A tester may validate scenarios such as:
Tenant A User → Request → Tenant B Resource

The assessment can examine whether changing an identifier, modifying a request or manipulating application behavior allows access to another tenant's information.

Relevant testing areas can include:
• Object level authorization
• BOLA
• IDOR
• Role based access
• API authorization
• Direct object references
• Cross tenant data access
• Administrative permissions

The objective is to verify that authorization is enforced server side rather than relying only on values presented by the client.

Testing should represent the actual permission model of the SaaS platform.

Depending on the application, this can include:
• Standard user
• Account owner
• Manager
• Read only user
• Support user
• Administrator
• Privileged administrator

Testing should also consider accounts belonging to different tenants.

For example:
Tenant A Administrator

versus

Tenant B Standard User

This allows the security assessment to examine whether permissions are correctly enforced across both role and tenant boundaries.

Yes, when APIs provide access to tenant data or functionality.

Many SaaS applications use APIs for almost every major customer action.

A tester should therefore consider:
• API authentication
• API authorization
• BOLA
• Token handling
• Object identifiers
• Sensitive data exposure
• Rate limiting
• Privilege escalation
• Business logic

A multi tenant vulnerability may exist in an API even when the visible web application appears secure.

NuageSEC provides API Security Testing across REST, GraphQL, SOAP and gRPC environments, including authentication, authorization, business logic and data protection testing.

https://www.nuagesec.com/api-security-testing-services

The assessment should use authorized test accounts from separate tenants.

The security team can then validate whether one tenant can access resources belonging to another through:
• Modified object identifiers
• Manipulated API requests
• Direct URL access
• Hidden application functions
• Export functionality
• Search functionality
• File access
• Shared resources

For example, if a request retrieves a customer record using an object identifier, changing that identifier should not expose a record belonging to another tenant.

The same principle should apply to files, invoices, reports, projects, users and other tenant owned resources.

Authentication determines whether the user is legitimate.

Authorization determines what that legitimate user can access.

Both matter in a multi tenant SaaS environment.

Testing can include:
• Login controls
• MFA
• Session management
• JWT
• OAuth
• Password reset
• Role permissions
• Privilege escalation
• Session invalidation
• Server side authorization

A successful login should never automatically provide access to resources outside the user's assigned tenant or role.

Yes, particularly when business workflows affect customer data, subscriptions, permissions or financial transactions.

Examples include:
• Subscription upgrades
• Payments
• Discounts
• Refunds
• User invitations
• Account changes
• Data exports
• Approval workflows
• Usage limits

The security question is:
Can a user manipulate a legitimate workflow to bypass a tenant, role or business restriction?

Business logic testing generally requires manual validation because automated scanners cannot fully understand the intended behavior of a SaaS application's workflows.

Cloud infrastructure should be considered when it forms part of the authorized assessment scope.

Depending on the SaaS architecture, this may include:
• AWS
• Microsoft Azure
• Google Cloud
• Kubernetes
• Containers
• Storage
• IAM
• Databases
• Cloud networking

The scope should clearly identify which cloud resources are authorized for testing.

NuageSEC provides cloud penetration testing for AWS, Azure and Google Cloud environments.

https://www.nuagesec.com/services/cloud-penetration-testing

A multi tenant SaaS platform should consider penetration testing when:
• Preparing for enterprise onboarding
• Entering a major enterprise sales cycle
• Launching significant platform changes
• Introducing new APIs
• Changing authentication architecture
• Migrating cloud infrastructure
• Adding major integrations
• Preparing for a customer security assessment
• Addressing contractual security requirements

Testing should also be reconsidered when significant changes alter the application's attack surface.

There is no fixed cost for testing a multi tenant SaaS platform.

Pricing can depend on:
• Number of applications
• API scope
• Number of user roles
• Number of tenants used for testing
• Authentication complexity
• Business workflows
• Cloud infrastructure
• Testing depth
• Compliance requirements
• Retesting

A simple SaaS application with a small attack surface will require a different level of effort from a large multi tenant platform with extensive APIs and complex authorization.

The most useful way to compare quotations is to compare the actual testing scope and deliverables rather than price alone.

https://www.nuagesec.com/blog/how-to-choose-vapt-company

The final report should clearly document what was tested.

Depending on the engagement, it can include:
• Assessment scope
• Applications and APIs tested
• User roles tested
• Testing dates
• Methodology
• Vulnerability severity
• Technical evidence
• Proof of concept
• Business impact
• Remediation recommendations
• Retesting results

For enterprise customers, clearly documenting the tested scope is particularly important because the report may be reviewed by security and procurement teams.

https://www.nuagesec.com/blog/what-does-a-vapt-report-include

Provide enough information to understand the platform and its tenant architecture.

Useful inputs include:
• Application URLs
• API documentation
• Test accounts
• Tenant accounts
• User roles
• Authentication details
• Critical workflows
• Testing environment
• Relevant cloud information
• Customer security requirements

Clearly identifying tenant boundaries helps the testing team validate whether authorization controls work correctly across organizations.

Before testing begins, confirm that the scope addresses the actual customer attack surface.

Ask:
Are the customer facing applications included?
Are relevant APIs included?
Will separate tenant accounts be tested?
Will user roles be tested?
Will tenant isolation be validated?
Will authentication and authorization be assessed?
Will business logic be tested?
Are relevant cloud assets included?
Does the scope address enterprise customer requirements?

If the answer is yes, the assessment is more likely to provide meaningful security evidence for enterprise onboarding.

Multi tenant SaaS platforms require security testing that reflects how customers, users, APIs and business workflows interact.

A properly scoped assessment can identify weaknesses involving tenant isolation, authorization, authentication, APIs, privilege escalation and business logic before they become customer facing security issues.

NuageSEC provides VAPT and penetration testing services for SaaS environments, with assessments that can be scoped around applications, APIs, cloud infrastructure and user access controls.

If your SaaS company is preparing for an enterprise security review or customer requested penetration test, get the scope reviewed before testing begins.

REQUEST A MULTI TENANT SAAS PENETRATION TESTING ASSESSMENT.

https://www.nuagesec.com/contact