The Most Common Vulnerabilities in Multi-Tenant SaaS Penetration Testing

A consistent pattern emerges across manual multi-tenant SaaS penetration testing engagements: the highest-impact vulnerabilities are rarely the ones an automated scanner finds first. 

Broken Access Control in Multi-Tenant SaaS Applications

What it is.

Broken Access Control occurs when an API endpoint resolves a resource identifier supplied by the client (typically an integer, UUID, or token) without verifying that the requesting user is authorized to access the object that identifier resolves to. In a multi-tenant SaaS context, Broken Object Level Access Control becomes a cross-tenant data access vector: a legitimate user in tenant A supplies an identifier belonging to tenant B and the server responds with tenant B's data.

Why automated scanners miss it.

Broken Object Level Access Control has no syntactic signature. A scanner can confirm that an endpoint exists and that it returns HTTP 200, but it has no knowledge of which object IDs belong to which tenants, and therefore no way to determine whether a given response represents an unauthorized cross-tenant disclosure. Detecting Broken Object-Level Access Control requires an authenticated session in tenant A, a set of known or enumerable object IDs from tenant B, and the judgment that the returned resource belongs to a different organizational context. That context exists only through human analysis during the engagement.

What it looks like in practice. 

In an engagement against a multi-tenant e-learning SaaS platform serving enterprise customers, pentesters identified that a file download endpoint accepted a `id` parameter as a plain integer; sequential and trivially enumerable. A Platform Admin authenticated to tenant 2 was able to supply an ID known to belong to a learner in tenant 1, and the server returned the correct PDF without any cross-tenant ownership check. The parameter was processed as a simple lookup: if the record exists, return it. The fix requires either scoping the endpoint to certificates owned by the requesting tenant's learners, or validating the requesting account's organizational relationship to the certificate before serving it.

Typical severity.

High, CVSS 4.0 score of 6.1 in this case. Though the business impact exceeded what the score reflects, because certificate IDs were sequential integers making automated enumeration trivial, and the exposed data included learner identity information with cross-tenant regulatory implications.

In our SaaS engagements, Broken Object Level Access Control and IDOR vulnerabilities appear across a wide range of application types, most commonly at tenant-scoped API endpoints that applied function-level authorization checks (verifying the user was logged in and had the right role) but omitted object-level checks (verifying the user was entitled to the specific record requested).

Tenant Isolation Failures in Multi-Tenant SaaS

What it is.

Tenant isolation is the enforcement boundary that prevents one customer's data, actions, and context from crossing into another's. A tenant isolation failure occurs when that boundary is enforced inconsistently. Typically, when the application relies on a client-supplied tenant or account identifier in the request body or path, accepts it at face value server-side, and performs write or read operations against the target resource without a secondary ownership check against the authenticated session.

Why automated scanners miss it. 

Tenant isolation failures require two valid, independent sessions across two separate tenants to demonstrate. A scanner authenticates as one user and probes endpoints it can discover, but it has no concept of "another tenant's resource identifiers" to substitute into requests. It cannot reason about what the advertiser ID in a GraphQL mutation *should* resolve to, given the authenticated principal, let alone recognize that a successful mutation using a foreign ID represents a breach. The attack surface only becomes visible when a tester controls both sides of the tenant boundary simultaneously.

What it looked like in practice.

During an engagement against an adtech SaaS platform, pentesters discovered that a GraphQL `UpdateAdvertiser` mutation accepted an `add` parameter in the request body with no server-side check that the authenticated user owned that advertiser account. Changing the `adId` to another account's integer ID (sequential and therefore predictable) allowed a user from account A to overwrite all profile and contact information for account B, including the contact email address. After the mutation, the two accounts were linked in the application's UI, and each user could switch into the other's account context via the application's built-in "Change Advertiser" feature. The attacker effectively hijacked the account by rewriting its contact email. The CVSS 4.0 score was 9.8 Critical, with exploitability rated high across confidentiality, integrity, and availability dimensions.

Typical severity.

Critical to High. Tenant isolation failures that include write access, like modifying another tenant's records rather than just reading them, almost always land at Critical because they combine data exfiltration with account manipulation in a single request.

In our SaaS penetration testing engagements, cross-tenant access control failures occurred across multiple engagement types, from advertising platforms to healthcare scheduling tools, with sequential or predictable identifiers as the common enabling factor in most exploitable cases.

Auth Bypass in SaaS Applications

What it is.

Auth bypass in a SaaS context refers to any path through which an unauthenticated or under-authenticated actor obtains access to resources, capabilities, or tokens that the application intends to gate behind a completed authentication check. This includes omissions of the OAuth state parameter, client-side logic used to determine authorization, token chains that can be seeded with attacker-controlled input, and integration flows that skip email verification or identity binding.

Why automated scanners miss it.

Auth bypass via logic flaws has no payload. It is not SQL injection with a quote character or XSS with an angle bracket. There is no string a scanner can fuzz for. The vulnerability exists in the *sequence* of requests and the *assumptions* built into that sequence. A scanner submitting a single request to an authentication endpoint will see a 400 or a 401 and move on. The bypass lies in how requests interact with each other across multiple steps, services, and trust assumptions that the developer documented nowhere.

What it looked like in practice.

During an engagement against a SaaS software platform with a third-party OAuth integration, pentesters found that the OAuth callback flow lacked a state parameter or an equivalent binding check. An attacker who registered an account at the third-party OAuth provider using a victim's existing email address and registration at the third party did not require email verification, so it could initiate the integration flow and, on callback to the SaaS platform, be authenticated as the victim user because the platform matched identity solely by email address. The victim's tenant, data, and administrative privileges were immediately accessible to the attacker. Crucially, the issued JWTs persisted indefinitely unless the integration was manually removed, extending the attacker's access window. CVSS 4.0: 10.0 Critical.

Typical severity.

Critical when the bypass results in account takeover or direct tenant access; High when the bypass is constrained to specific flows or requires partial knowledge of the victim account. Auth bypass flaws that exploit integration trust chains (OAuth, SSO, webhook callbacks) tend toward Critical because they are often chainable and because the legitimate user has no reliable way to detect the intrusion.

In our SaaS penetration testing engagements, auth bypass vulnerabilities most commonly appeared not in the primary login flow but in secondary integration and onboarding workflows, where the application correctly hardened the main authentication path but inherited trust from a third-party service with weaker identity binding guarantees.

Business Logic Flaws in Multi-Tenant SaaS

What it is.

A business logic flaw exists when an application correctly implements a feature as specified but the specification itself contains a gap that allows an attacker to use the feature in a way it was never intended. In multi-tenant SaaS, this most commonly manifests as role-based access controls that are enforced on the UI layer but not on underlying API endpoints, or as administrative interfaces exposed to lower-privileged users because the developer assumed the interface would only ever be reached through the UI flow.

Why automated scanners miss it.

There is no CVE for " Manager can enumerate and modify all user accounts by navigating to the API root." The application is behaving exactly as coded. A scanner cannot distinguish between an API endpoint that is intentionally open to all authenticated users and one that should be restricted but was missed during development. That distinction requires understanding the intended access model, and that model lives in documentation, architecture diagrams, and kickoff conversations, not in HTTP responses.

What it looked like in practice.

In an engagement against a marketing analytics SaaS platform, testers logged in as a lower-privileged role and navigated directly to the application's API root, which was powered by the Django REST Framework and rendered an explorable, browsable interface. From that interface, the Data Manager account could access `/api/userupdates/`, read all user records including PII and `is_staff` flags, and issue POST and PATCH requests to create new users or modify existing ones. The same interface exposed organization creation and cross-organization data. No error, no redirect, no permission check. The application correctly blocked the Data Manager from accessing these functions via the product UI; however, it did not impose the same restrictions on the underlying API. CVSS 4.0: 9.3 Critical.

Typical severity.

Critical to High, depending on what the exposed functionality controls. Business logic flaws that expose privileged write operations (user management, organization configuration, billing parameters) land at Critical. Read-only exposure of data intended for higher roles typically lands at High.

Business logic flaws are the hardest category to assign severity to, because the definition of "intended behavior" varies by application. What is consistent across our SaaS penetration testing cohort is that they appeared almost exclusively in API endpoints reachable from authenticated lower-privileged sessions. Places where the developer's mental model assumed the UI was the only consumer of the API.

What This Means for Your Next Engagement

The recurring pattern wasn't an injection attack or unpatched software. It was application logic. Every vulnerability in this analysis required understanding tenants, identities, workflows, and intended behavior. That's why manual testing continues to find vulnerabilities that automated tools simply aren't designed to detect.

A manual multi-tenant SaaS penetration testing engagement, one where the pentester operates with valid credentials across multiple tenant accounts and a thorough understanding of your access model, is the only mechanism that surfaces this class of vulnerability before an adversary does.

If you want to see what vulnerabilities look like in your own application rather than in aggregate, book a consultation with Software Secured. We'll scope an engagement that reflects how your multi-tenant architecture actually works.