SaaS environments fail in characteristic ways. They rarely break at the perimeter or because controls are absent entirely, they break because authorization logic is incomplete, tenant isolation is inconsistent, and the APIs that hold these platforms together trust state they should not. Across 119 penetration tests conducted for Tech, Software & SaaS clients in 2025, 755 vulnerabilities concentrated in access control, sensitive data exposure, and business logic.
Two patterns make the SaaS sector distinctive. The first concerns API security: almost every SaaS finding was reachable over the network and required no user interaction to exploit, reflecting how much of the modern SaaS attack surface lives in JSON APIs rather than in the rendered UI. The second concerns trust boundaries: SaaS showed the highest rate of CVSS scope change of any industry, a consequence of microservice architectures and shared trust assumptions, where exploitation in one service routinely crosses authorization domains into another.
The data behind this article comes from our 2025 Annual Penetration Testing Review, an analysis of 3,294 findings across 660 engagements and 145 organizations. The sections that follow distill the most common SaaS vulnerabilities from that dataset: what falls in scope during a SaaS penetration test, the severity profile and density of SaaS pentest findings, the CWEs that recur most often and more.
What SaaS Security Assessments Usually Cover
The scope of a SaaS penetration test is shaped by the architecture beneath it: a multi-tenant web application sitting on top of an API surface, backed by a microservice or service-oriented backend, integrated with third-party services, and deployed on cloud infrastructure. Web Application Security Testing dominated assessments of SaaS applications in 2025, accounting for 62.4% of all engagements in the sector.
That distribution is more nuanced than it appears. While dedicated API Security Testing represented only 3.4% of SaaS engagements, most web application pentests include the underlying API layer in scope by default — the frontend is rarely separable from the JSON-driven backend powering it. SaaS engagements also showed the largest share of Mixed/Specialized assessments of any sector at 19.7%, reflecting how often these scopes extend into source code review, cloud configuration audits, GraphQL-specific testing, or assessments of LLM-integrated features.
Within that scope, several systems consistently attract testing attention: customer-facing tenant portals, admin and operator consoles, public REST and GraphQL APIs, internal service-to-service APIs, identity providers and SSO integrations, and the authorization and session layers that tie them together. Object-level authorization — whether a user in tenant X can access a resource belonging to tenant Z — typically produces the most findings of any single area, because correct enforcement is required at every endpoint rather than at a single perimeter.
Three architectural facts shape why SaaS pentests surface the findings they do. The primary trust boundary under test is between tenants, not between the internet and the application; tenant data isolation is what multi-tenancy is built to enforce, and where it most often fails. Business logic is distributed across services, which means authorization decisions are made in multiple places using subtly different assumptions. Release cadence outpaces most security review cycles, leaving newly added endpoints, feature flags, and third-party integrations as a recurring source of fresh exposure.
Severity and Finding Volume in SaaS Pentests
SaaS engagements produced more findings per project than the overall 2025 pentest population: 6.34 vulnerabilities per assessment on average, against a cross-industry average of 4.99 findings per project. Across 119 SaaS engagements, that added up to 755 SaaS vulnerabilities, a higher density that reflects both the breadth of attack surface in modern SaaS architectures and the way testing scopes routinely extend across web, API, identity, and cloud layers in a single engagement.
The severity profile sits closer to the middle of the pack. High and Critical findings together accounted for 14.3% of SaaS pentest results, lower than Healthcare & Pharmaceutical, Oil, Gas & Energy, and Insurance, but materially higher than e-Comm & Retail and Finance & Fintech. The SaaS sector vulnerabilities sit in the middle of the severity distribution: not skewed toward catastrophic individual findings the way regulated or legacy-heavy sectors are, and not as cleanly weighted toward Low and Medium as transactional sectors with mature application security programs.
The combination of higher volume and mid-range severity reflects something specific about SaaS security maturity. Baseline technical vulnerabilities, like missing authentication, exposed admin interfaces or unencrypted transports are largely absent from SaaS pentest reports. What remains is a long tail of authorization edge cases, information disclosure issues, business-logic flaws, and configuration weaknesses that individually fall into Medium severity but collectively define the residual SaaS security risks of mature environments.
Reading 14.3% as comforting would be a mistake. Severity ratings are calibrated against generic CVSS impact dimensions, which under-represent two failure modes specific to SaaS: tenant boundary breaches, where a single Medium-severity IDOR can expose another customer’s data, and chained exploitation paths, where critical vulnerabilities emerge from combining two or three otherwise unremarkable security weaknesses. The SaaS security findings in this dataset reinforce a recurring theme from the broader 2025 results — the SaaS industry vulnerabilities with the highest real-world impact are rarely the most technically dramatic.
The Most Common SaaS Pentest Findings
Insecure APIs are a common vulnerability in SaaS applications, where issues such as inadequate authentication and insufficient input validation can lead to unauthorized data access and significant data breaches. The CWEs below describe how those failures show up in the 2025 dataset.
CWE-200 — Sensitive Information Exposure. The most common SaaS CWE rarely takes the form of a textbook data dump. It surfaces as verbose API responses returning unrendered fields, JWT payloads carrying internal metadata, debug headers in production, or admin endpoints returning customer data alongside requested objects. These findings rarely break a system on their own, but they let an attacker access sensitive data through later authorization attacks — the connective tissue behind most unauthorized data access scenarios that pentests surface.
CWE-284 — Improper Access Control. Broken Access Control is the most common risk in modern web applications, appearing in nearly 100% of tested applications, and the 2025 SaaS findings sit firmly within that pattern. The category spans access control issues from tenant boundary violations to horizontal privilege failures and privilege escalation where role-based access controls are enforced in the UI but not the API. In multi-tenant systems, weak access controls of this kind are the most common way to gain unauthorized access to customer data, escalate access, or extract internal data without compromising a credential.
CWE-79 — Cross-Site Scripting. XSS sits in SaaS’s top three but not in healthcare, energy, or insurance pentest results. Two factors explain it: the high density of user-supplied rich text in modern SaaS products, and the speed of frontend evolution outpacing input and output sanitization. AI-generated code may be vulnerable to cross-site scripting (XSS) 86% of the time, highlighting a significant blind spot in cybersecurity that is likely accelerating the trend. Stored XSS in admin or operator views is particularly dangerous — a single tenant payload can hit a support engineer’s session and pivot into internal systems.
The remainder of the top SaaS vulnerabilities reveals a long tail of operational weaknesses. Rate-limiting failures (CWE-799) expose business logic vulnerabilities enabling brute-force attempts and account enumeration. Unrestricted file upload (CWE-434) ties to user-generated content and integration workflows, and verbose error messages (CWE-209) layer onto the information disclosure picture.
Security Misconfiguration has risen to the second most common risk in modern web applications, involving improper setup of security settings such as leaving default passwords active or keeping cloud storage buckets open to the public. In SaaS pentests, this surfaces primarily as protection mechanism failures (CWE-693) — controls that exist but are bypassable through unexpected request paths.
Together, these findings describe a profile where critical, externally exposed gaps are rare. What remains is the accumulation of inadequate access controls, business-logic weaknesses, and information leakage inside authenticated workflows — a risk surface that quietly puts critical data within reach of motivated insiders or compromised accounts.
Primary Attack Vectors in SaaS Penetration Testing
The SaaS sector showed the highest concentration of network-exploitable vulnerabilities of any industry assessed: almost all findings are reachable remotely, most require no user interaction, and the majority can be triggered with low or no privileges. SaaS also showed the highest rate of CVSS scope change of any industry, a marker of microservice architectures where exploitation in one service crosses authorization domains into another.
The composition changes once attackers are inside. SOC 2-driven pentests, which run predominantly against SaaS platforms, show that roughly 38% of findings involve an authenticated user abusing permissions. The category captures the BOLA, IDOR, tenant boundary, and privilege escalation issues at the top of the SaaS CWE list. The pattern echoes insider threats in shape, even when the actor is external to the organization.
Information leakage and reconnaissance vectors account for around 25% of SaaS-relevant attack patterns — verbose error messages, debug headers, observable response discrepancies, and overly informative API connections that let an attacker map the application before exploiting it. Session and token abuse adds another ~14%, surfacing as predictable session identifiers, weak token rotation, or sessions that survive logout — exactly the workflow conditions a thorough security review should catch but routinely misses.
Smaller categories are instructive. Cryptographic and protection-mechanism weaknesses represent ~13% — controls that exist but are misconfigured. Unauthenticated external access accounts for only ~7%, a notable reversal from older pentest patterns. Chained exploitation is just ~3% by count but produces the highest-impact outcomes, frequently turning a routine security incident into account takeover or tenant compromise.
The attack-vector profile differs noticeably from the general pentest population. Unauthenticated access and brute force attacks against externally exposed services are common findings across many sectors but appear infrequently in SaaS pentests, where perimeter controls, rate limiting, and MFA have been broadly adopted. The risk has migrated inward, into the authorization, session, and integration layers. The most common vulnerabilities in SaaS are no longer about getting through the front door — they are about what authenticated users and connected services can do once inside it.
What These Findings Mean
The SaaS attack profile is not accidental. Multi-tenancy, microservice decomposition, and continuous release create exactly the conditions the 2025 data describes: most exploitation requires authentication; trust boundaries live in code rather than infrastructure; and failure modes accumulate across services rather than concentrating at a single perimeter.
The most consistent interpretive blind spot in SaaS security findings is how vulnerabilities combine. CVSS scores each finding in isolation against generic impact dimensions, but SaaS exploitation rarely happens in isolation. A Medium-severity IDOR plus a Medium-severity information leak plus legitimate access from a low-privilege tenant account does not sum to three Mediums of operational impact — it produces account takeover. Severity ratings miss that the security gaps that matter most are the ones that connect.
Release velocity is the structural reason the long tail of SaaS findings exists. Most SaaS organizations ship faster than their security review cycles can keep pace with, leaving newly added endpoints, feature flags, and integration points as a steady source of fresh exposure. Integration security is a particular blind spot — third-party services and webhooks accumulate between scheduled reviews, and CWE-693 and CWE-799 findings routinely appear in code that has since drifted from its baseline.
Overall, the dataset describes a discipline shifting from defense at the perimeter to defense inside the application. SaaS security teams who internalize that shift treat findings as portfolios rather than checklists, monitor potential security gaps as they emerge across releases, and measure SaaS security posture by how consistently authorization is enforced rather than by remediated-CVE counts. The most common SaaS security risks reward that kind of attention.
Where SaaS Security Programs Should Focus
Authorization testing should span tenant and service boundaries, not just user roles within a single tenant. Access management is generally well-covered at the perimeter; the underspecified surfaces are the cross-tenant edge and the service-to-service interfaces, where authorization decisions are routinely assumed rather than enforced. Including a second tenant in scope, plus explicit service-to-service auth tests, surfaces issues that single-tenant assessments systematically miss.
API response payloads warrant audit, not just functional verification. CWE-200 in SaaS rarely manifests as missing access control; it manifests as endpoints returning more fields than the frontend renders, JWT payloads carrying internal metadata, and admin endpoints whose responses include adjacent objects beyond the requested resource. Listing every field every endpoint returns, then asking whether each is necessary, catches a meaningful share of these issues before they reach a pentest.
Rate limiting needs to extend beyond authentication endpoints. Login throttling is now widely deployed; password reset, registration, account lookup, search, and bulk operations frequently are not. CWE-799 findings in SaaS appear precisely at these endpoints — points of enumeration, resource exhaustion, or business-logic abuse that don’t look like brute force at first glance but enable account takeover, scraping, or denial of service when chained.
Integration and webhook surfaces deserve periodic inventory and trust reduction. Third-party cloud services accumulate over time, OAuth scopes drift wider than the original use case required, and webhook callbacks go unaudited between releases. The useful question is not “is this integration secure?” but “what would an attacker reach if this integration were compromised tomorrow?” — the answer in most SaaS apps is broader than expected.
Session and token lifecycle is a frequent blind spot in long-running SaaS workflows. Common issues with identity and authentication include session hijacking, credential stuffing, and failing to deprovision accounts for former employees. The harder cases involve post-login state changes: active sessions that persist after a user is deleted from a tenant, role downgrades that do not invalidate cached entitlements, refresh tokens not rotated on use, or OAuth tokens whose scopes silently widen. Testing lifecycle under workflow conditions exposes failure modes that severity-by-CWE rankings underweight.
Conclusion
The 2025 findings reframe what SaaS security actually requires. Authentication, perimeter controls, and basic encryption are largely solved; what now defines SaaS security is making authorization correct and consistent across endpoints, services, and tenants.
Penetration testing remains essential for SaaS providers, and regular security assessments timed to match release cadence consistently outperform annual checkpoints. Scanners find missing controls; pentesters find controls that exist but fail under real workflow conditions — exactly where modern data breaches in the sector tend to begin, and where incident response is hardest after the fact.
The most damaging incidents are not the ones that breach the front door; they are the ones that quietly exploit what is already inside.
FAQ
How often should a SaaS company perform a penetration test?
Most SaaS programs benefit from regular security assessments timed to release cadence rather than annual checkpoints. SOC 2 and ISO 27001 require regular security audits at an annual minimum, but every new feature, integration, or admin endpoint introduces new attack surface — and findings accumulate faster than annual reviews can catch them. Quarterly or per-release testing for high-change components, paired with broader annual engagements, is a common pattern.
What are the emerging AI risks for SaaS security?
AI-generated code introduces input-handling flaws at scale, accelerating the XSS pattern already visible in SaaS pentest data. Unauthorized AI use, referred to as “Shadow AI,” can lead to sensitive data being uploaded to unvetted platforms when employees paste customer or internal information into consumer AI tools. Addressing SaaS vulnerabilities of this kind requires scoping AI-related surfaces explicitly into the next assessment.
How are SaaS pentest findings typically prioritized for remediation?
Severity ratings are the starting point, but SaaS findings often need re-prioritization based on chaining potential. A Medium-severity IDOR may matter more than a High-severity finding if it crosses a tenant boundary or combines with information leakage to enable account takeover. Triaging by combination is what separates effective SaaS remediation from a CVE-counting exercise.
