The most common vulnerabilities in SaaS applications and how to detect them

By the QuantumSec team

SaaS applications have a different attack surface from that of a traditional web application. They serve multiple customers on the same infrastructure, expose complex APIs, manage subscriptions and permissions, and integrate dozens of external services. These characteristics generate specific vulnerabilities that automated scanners rarely detect and that require pentesters who understand the product's business model.

IDOR and multi-tenant isolation failures

Insecure Direct Object Reference (IDOR) is the most frequent vulnerability in SaaS. It occurs when an endpoint accepts an identifier without verifying that the authenticated user has permission to access that specific resource. In a multi-tenant SaaS, an IDOR can grant access to another customer's data: documents, activity logs, billing information or internal configuration. Example: GET /api/invoices/12345 returns customer 12345's invoice even though the token belongs to customer 67890. This flaw can be exploited at scale through ID enumeration.

Weak or misconfigured JWT tokens

JWT tokens are the standard authentication mechanism in SaaS, but an incorrect implementation generates critical vulnerabilities. The most frequent flaws: use of the "none" algorithm (a token with no verified signature), weak or predictable secrets in HS256, absence of "exp" claim validation (tokens that never expire), lack of "aud" validation that allows tokens to be reused across microservices, and tokens with excessive claims that leak internal information. A JWT with a weak algorithm can be forged to impersonate any user, including administrators.

Mass assignment in REST APIs

Mass assignment occurs when the API accepts additional unexpected fields in a request body and applies them directly to the data model. If the endpoint PATCH /api/users/{id} accepts an unanticipated "role": "admin" field, an attacker can escalate their privileges simply by including that field in the request. This flaw is especially frequent in SaaS built with frameworks such as Rails, Django REST Framework or NestJS, where automatic serialisation can expose fields that should not be writable.

Broken function-level authorization

In SaaS with multiple pricing plans, some functions should be restricted to certain plans. Broken function-level authorization occurs when the interface hides these functions from basic-plan users, but the API endpoints do not validate the tenant's plan. A Starter-plan user can call Enterprise-plan feature endpoints directly if access control lives only in the frontend. It also affects administration routes that assume only the admin knows about them but implement no role check in the backend.

Webhooks without signature validation

Webhooks are an attack vector that is frequently overlooked in SaaS. Without validating the HMAC signature of the payload, an attacker can send forged events to trigger actions (marking a payment as completed), intercept webhooks and extract sensitive data between customers, or flood the system with fake webhooks. Stripe, GitHub and most mature platforms sign their webhooks. Your SaaS should likewise validate the signature before processing any incoming event.

Data exposure in GraphQL APIs

GraphQL introduces specific risks that REST does not have. The most critical in SaaS: introspection enabled in production (exposes the entire schema), queries with no depth or complexity limit (denial-of-service attacks), absent field-level authorization (a field hidden in the UI is accessible via a direct query), and query batching that allows thousands of operations to run in a single request. IDOR also applies in GraphQL: if the resolver does not verify ownership of the queried node, a user can access other tenants' data.

Exposed secrets and credentials

It is common to find in SaaS: third-party API keys in endpoint responses (Stripe keys, SendGrid API keys, AWS credentials), secrets hardcoded in the frontend (in the bundle's JS files), internal tokens in error messages or accessible logs, and signed S3 URLs with an excessively long TTL. These flaws are especially serious because they often grant access to the company's entire infrastructure, not just one tenant's data.

Manipulable billing and subscription logic

Billing business logic is a critical area specific to SaaS. Typical vulnerabilities: race conditions in plan updates (downgrading while consuming a premium resource), bypassing usage limits by tampering with counters, access to higher-plan features during the grace period after a cancellation, and manipulable discount or coupon validation to obtain free subscriptions. These vulnerabilities have a direct financial impact and are hard to detect with automated tools.

FAQ

How do I know if my SaaS has multi-tenant isolation vulnerabilities?

The most reliable approach is to commission a SaaS-specialised penetration test where the team simulates being two different customers and attempts to access one customer's data from the other's account. As a preliminary measure, you can manually review that all your endpoints validate that the requested resource belongs to the authenticated tenant, not merely that the user is authenticated.

Do automated scanners detect these vulnerabilities?

Most do not. DAST scanners are good at detecting injection vulnerabilities (SQLi, XSS) and insecure configurations. But business logic flaws, IDOR between tenants, billing manipulation and function-level authorization problems require a pentester who understands the product and manually tests specific business flows.

How often should I run a penetration test on my SaaS?

The industry standard for SaaS is at least once a year, and additionally before major changes to the architecture, authentication or billing. If you are in the process of SOC 2 Type II or ISO 27001 certification, an annual pentest is usually an explicit requirement.