A SaaS platform does not protect only one organisation.

It may host hundreds or thousands of customers within the same application, infrastructure, databases, storage systems, and supporting services. Each customer expects its users, records, configurations, and business activity to remain separated from everyone else using the platform.

That makes SaaS VAPT different from testing a conventional standalone website. Finding vulnerability matters, but testers also need to understand whether one tenant can cross boundaries, whether ordinary users can reach privileged functionality, and whether shared components can expose information belonging to other customers.

OWASP identifies these as fundamental multi-tenant security concerns. Its guidance highlights risks including cross-tenant data leakage, broken tenant isolation, tenant impersonation, privilege escalation, insecure onboarding and offboarding, and shared-resource attacks.

For SaaS providers, those weaknesses can have an unusually large blast radius because a flaw in one shared control may affect many customers at once.

Multi-Tenancy Changes the Security Question

In a conventional application, an access-control vulnerability might expose another user’s record.

In a multi-tenant SaaS platform, the same class of vulnerability could expose another company’s records.

That difference changes the business impact considerably.

A tenant might store employee information, contracts, financial records, customer data, operational documents, API credentials, or commercially sensitive information inside the platform. If the application fails to enforce tenant separation consistently, an attacker may not need to compromise the underlying infrastructure to reach another customer’s information.

The application itself can become the route across the boundary.

Good SaaS security therefore depends on more than authentication. The platform must repeatedly answer two separate questions:

Who is this user?

Which tenant, objects, functions, and data is this user actually allowed to access?

SaaS VAPT tests whether those decisions remain correct when users deliberately manipulate requests, identifiers, roles, workflows, APIs, and application behaviour.

Five Boundaries a SaaS VAPT Assessment Should Challenge

A useful SaaS assessment should not treat the platform as a collection of pages to scan.

It should examine the trust boundaries that keep customers separated and restrict what different users can do.

1.    Tenant-to-Tenant Data Isolation

Tenant isolation is one of the most important security properties of a multi-tenant platform.

A logged-in user from Company A should not be able to retrieve a document, invoice, account record, dashboard, export, or configuration belonging to Company B simply by changing an identifier.

Yet these weaknesses can be surprisingly subtle.

An application might correctly protect the main record page while failing to apply the same control to a download endpoint. Search results may respect tenant boundaries while an export function does not. A background API could retrieve an object by ID without checking which tenant owns it.

OWASP’s multi-tenant guidance specifically warns about cross-tenant data leakage and insecure direct object references within shared SaaS architectures.

Testing therefore needs more than one user account.

Testers should ideally work with controlled accounts representing multiple tenants and different permission levels, then attempt to access resources across those boundaries.

The question is simple: Can Tenant A ever cause the platform to act on Tenant B’s data?

2.    User, Administrator, and Support Privileges

Tenant boundaries are only one layer of authorisation.

Most SaaS platforms also contain several levels of privilege within each tenant. There may be standard users, managers, billing administrators, organisation owners, support staff, platform administrators, and internal operational roles.

Every additional role creates another security boundary.

A normal user should not be able to change subscription settings simply by calling an administrator endpoint. A tenant administrator should not gain platform-wide privileges. Support tooling should not expose unrestricted customer data simply because it is intended for internal staff.

OWASP recommends validating permissions on every request and applying a deny-by-default model rather than assuming that authenticated users should have broad access.

This is especially important in SaaS products because role hierarchies frequently become more complicated as features and customer requirements expand.

A VAPT assessment should challenge those assumptions from several directions, including horizontal access between users at the same level and vertical escalation towards more privileged functions.

3.    APIs That Carry Tenant Context

Modern SaaS platforms depend heavily on APIs.

The web interface may simply provide the visible front end while most real actions happen through REST, GraphQL, mobile, partner, or internal API calls.

That makes API authorisation central to tenant security.

OWASP currently ranks Broken Object Level Authorization as API1 in its API Security Top 10. The weakness occurs when an API accepts an object identifier but does not properly verify that the authenticated user has permission to access that particular object.

In SaaS, the object may belong to another tenant.

For example, consider an endpoint such as:

GET /api/projects/7842

Changing 7842 to another valid project ID should never reveal a project simply because the identifier exists.

The same principle applies to modification and deletion.

An API that prevents users from viewing another tenant’s record but allows them to update or delete it still has a serious authorisation failure.

This is why API VAPT deserves particular attention within SaaS assessments. The tester needs to examine what happens behind the user interface, not simply whether visible pages behave correctly.

Developers and security teams can also use the OWASP API Security Top 10 as a useful reference when reviewing API-specific risks.

4.    Shared Databases, Storage, Caches, and Background Services

Not every tenant-isolation problem exists in the application interface.

Multi-tenant systems frequently share databases, object storage, caching layers, search indexes, message queues, background workers, reporting systems, and other infrastructure.

A mistake in any of these components can undermine otherwise strong application controls.

For example, an application might correctly restrict database queries by tenant but store generated reports in predictable cloud-storage paths. A shared cache could accidentally return one customer’s content to another. A background job might process the wrong tenant context after receiving manipulated input.

OWASP’s multi-tenant security guidance specifically identifies broken isolation across databases, caches, storage, and compute resources, as well as shared-resource poisoning risks.

Testing therefore needs to follow the complete data path where practical.

The important security boundary is not simply the page the customer sees. It is every shared component through which tenant data passes.

5.    Business Workflows That Assume Users Will Behave Normally

Some of the most damaging SaaS vulnerabilities do not involve unusual exploits.

They involve using legitimate functionality in ways the development team did not expect.

A SaaS product may allow administrators to invite users, change plans, issue credits, transfer ownership, create API keys, approve transactions, export data, or connect third-party services.

Each workflow contains business rules.

What happens if a user repeats an action hundreds of times? Can an invitation intended for one tenant be reused elsewhere? Can a normal user call a hidden administrator function directly? Can ownership be transferred without appropriate verification?

OWASP’s API Top 10 includes unrestricted access to sensitive business flows because attackers can abuse legitimate functionality when applications fail to enforce appropriate restrictions.

These issues often require human understanding of how the SaaS product is meant to work.

Our article on business logic vulnerabilities covers this problem in more depth because these weaknesses are exactly where scanner-only approaches frequently struggle.

What a Cross-Tenant Vulnerability Can Look Like

Consider a project-management SaaS platform used by multiple businesses.

Each tenant can create projects, upload files, invite employees, and generate reports.

A user from Company A requests one of its reports:

GET /api/reports/12451

The server authenticates the user successfully and retrieves report 12451.

During testing, the assessor changes the identifier:

GET /api/reports/12452

Report 12452 belongs to Company B.

If the application checks only whether the user is logged in, the second request may succeed. The attacker now has cross-tenant access even though they never bypassed authentication.

The failure is authorisation.

A stronger design verifies not only that the user has a valid session, but also that the requested report belongs to a tenant the user is authorised to access.

OWASP recommends performing object-level authorisation checks for every API function that accesses records based on identifiers supplied by the client.

The same testing principle should be applied across downloads, exports, comments, messages, attachments, invoices, integrations, user-management functions, and other tenant-owned objects.

One missed check can be enough.

Why Automated Scanning Is Not Enough for SaaS Platforms

Automated scanners remain useful.

They can identify known vulnerabilities, outdated software, security headers, exposed services, insecure configurations, and many common application weaknesses quickly across a large target.

What they cannot reliably understand is who should be allowed to do what.

A scanner does not inherently know that User A belongs to Tenant A while invoice 458 belongs to Tenant B.

It may not understand that only organisation owners should be allowed to create API keys. It may struggle to recognise that a user can manipulate an onboarding workflow to join another tenant. It cannot always determine whether an unusual sequence of legitimate actions violates the application’s intended business rules.

These weaknesses require context.

Manual testing lets an assessor compare roles, manipulate tenant identifiers, alter API requests, test workflow assumptions, and observe how the application behaves when users deliberately step outside the expected path.

This is one reason SaaS assessments should combine automated coverage with manual investigation rather than relying on vulnerability scanning alone.

The SaaS Admin Layer Deserves Separate Attention

Customer-facing functionality receives most of the product team’s attention, but internal administration tooling can carry substantially greater privileges.

Support teams may need to search customer accounts, impersonate users for troubleshooting, reset settings, modify subscriptions, review logs, or access operational information.

Platform administrators may have even broader capabilities.

If attackers gain access to these functions, they may bypass tenant isolation entirely.

A SaaS VAPT assessment should therefore consider:

  • How internal administrators authenticate
  • Whether MFA protects privileged accounts
  • How support impersonation works
  • Whether privileged actions are logged
  • Whether administrative APIs are externally reachable
  • Whether ordinary users can discover or invoke admin functions
  • How permissions differ between customer admins and platform admins

These controls deserve scrutiny because the application may have excellent customer-level tenant separation while still providing an easier path through a privileged operational interface.

Test SaaS Without Creating Unnecessary Customer Risk

Testing a live multi-tenant SaaS platform requires careful planning.

The provider cannot treat production like an isolated laboratory because real customer data and services may share the same infrastructure.

The preferred approach depends on the architecture.

A representative staging environment can allow deeper testing where production exploitation would create unacceptable risk. However, the staging environment must meaningfully reflect production security controls if conclusions are going to be drawn from it.

Production testing may still be appropriate for selected checks where the methodology, permissions, test accounts, and limits are clearly agreed.

A practical SaaS test plan may use:

Dedicated test tenants. Separate organisations allow the assessor to attempt controlled cross-tenant actions without accessing genuine customer information.

Multiple user roles. Testing with standard users, tenant administrators, and other authorised roles helps expose privilege boundaries.

Defined prohibited actions. Potentially disruptive techniques should be explicitly restricted unless there is a safe and approved way to perform them.

Known data markers. Test records can make cross-tenant leakage easier to identify without relying on real customer content.

Production-aware scheduling. Potentially intensive tests can be controlled to reduce the chance of affecting customers.

The goal is to test the isolation model meaningfully without creating the incident the assessment is supposed to prevent.

Use VAPT Findings to Improve the SaaS Product

The most valuable SaaS penetration test should change more than the current release. Suppose the assessment finds three separate cross-tenant authorisation failures. Fixing those three endpoints individually resolves the immediate vulnerabilities. It may not resolve the underlying problem.

The more important question is why three teams or functions were able to make the same mistake. Perhaps tenant checks are implemented manually in each controller. Maybe developers can query records without a mandatory tenant context. Perhaps security tests cover authentication but not cross-tenant authorisation.

The long-term fix may therefore involve changing architecture, development standards, middleware, automated testing, or code-review requirements. OWASP’s Application Security Verification Standard provides a structured basis for defining and verifying application security requirements.

SaaS development teams can use the OWASP Application Security Verification Standard alongside their own secure-development practices to make lessons from VAPT repeatable. That is how testing begins to reduce future vulnerabilities rather than repeatedly discovering variations of the same defect.

Final Thoughts

Customers using a SaaS platform rarely see the complexity behind it. They see an account, their users, and their information. Behind that simple experience may sit shared databases, cloud infrastructure, APIs, storage, queues, administrative tools, background processes, and integrations serving many organisations at once.

Every layer must preserve the same basic promise: one customer cannot become another customer’s security problem. SaaS VAPT helps challenge that promise before attackers do. The most useful assessments focus on tenant separation, authorisation, privileged functions, APIs, shared services, and product-specific workflows rather than treating the platform as an ordinary website with a login page.

For SaaS providers preparing to onboard larger customers, release major platform changes, or independently validate the security of a multi-tenant architecture, Aegixis can conduct SaaS-focused VAPT across the application and relevant supporting components.

The assessment can test realistic tenant and privilege boundaries, identify exploitable weaknesses, and provide developers with practical remediation guidance so security improvements strengthen the platform for every customer using it. For more information, refer to Aegixis VAPT Services.