Insights from SOC 2-driven penetration testing engagements Blaze Information Security conducted last year reveal patterns in the types of issues organizations encounter when evaluating the security of their systems. The article below is based on the data from our 2025 Annual Penetration Testing Review.Â
For organizations looking to obtain their SOC 2 certification or preparing for a SOC 2 pentest assessment, this article outlines the common SOC 2 penetration testing findings most likely to surface during testing and the risks they can create in real systems.
What SOC 2 Penetration Tests Typically Assess
SOC 2 evaluations focus on systems that process or store sensitive customer information. As a result, penetration tests conducted in support of SOC 2 audits tend to concentrate on externally exposed attack surfaces and application-layer components.
Pentesting engagements typically assess publicly accessible components such as customer-facing web applications, APIs, and exposed cloud services, with internal penetration testing sometimes included to validate broader security controls such as network segmentation and baseline configuration management.
Because these environments are typically multi-user platforms such as SaaS products or customer-facing applications, many security risks revolve around how identity and permissions are implemented. The critical question often becomes not whether authentication exists, but whether users can access resources or perform actions beyond their intended privileges.
Before examining the specific vulnerability categories, it is helpful to look at how findings are distributed by severity in SOC 2 penetration testing engagements.
Severity Distribution of SOC 2 Pentest Findings
The chart above illustrates the severity distribution observed during SOC 2-driven penetration testing engagements. While lower-severity issues represent a significant portion of findings, medium and high-severity vulnerabilities remain common, demonstrating that compliance-focused environments still contain meaningful security weaknesses.
This distribution highlights an important aspect of penetration testing results: the value of these assessments lies not only in identifying critical vulnerabilities, but also in revealing systemic weaknesses that could enable larger attack chains if left unaddressed.
Across the analyzed engagements, SOC 2 penetration tests identified an average of 7.0 vulnerabilities per project, providing a useful benchmark for teams preparing for similar assessments.
The Most Common SOC 2 Vulnerabilities
The most common SOC 2 penetration testing findings tend to cluster around how SaaS applications handle trust, identity, state, and data exposure. In environments designed for many users, multiple roles, and often multiple tenants, small weaknesses in these areas can have outsized consequences.
The findings below provide practical insight into application-layer data security weaknesses in SaaS environments.
Improper Access Control (CWE-284)
One of the clearest patterns that SOC 2 penetration testing reveals is the prevalence of access control weaknesses. They occur when the application fails to enforce whether a user should be allowed to access a resource, perform an action, or invoke a function.
In SaaS environments, CWE-284 often appears as cross-tenant access, horizontal privilege escalation, or exposure of administrative actions to non-administrative users. A user may be authenticated correctly, but still be able to retrieve another customer’s records, update objects outside their scope, or reach functionality intended only for internal or privileged roles. The impact is usually direct: unauthorized access to customer data, violation of tenant isolation, or modification of business-critical records.
Exposure of Sensitive Information (CWE-200)
Sensitive information exposure remains one of the most frequent weakness categories in SOC 2 assessments. It covers situations in which an application returns or reveals data that should not be available to the requesting user or external parties.
In SaaS products, this commonly includes API responses that expose excessive fields, internal identifiers that make object enumeration easier, leaked configuration data, or tokens and secrets appearing in logs or debugging output. Even when the exposed data does not immediately allow account takeover, it frequently enables follow-on attacks by helping attackers understand account structure, internal architecture, or resource naming conventions. In multi-tenant SaaS platforms, these failures can escalate from isolated exposure to customer-facing data breaches.
Information Exposure Through Error Messages (CWE-209)
Verbose error handling is another recurring finding in SOC 2-related penetration testing. Applications often reveal stack traces, database errors, internal paths, or details about backend validation when unexpected conditions occur.
In a SaaS context, those details help attackers map internal services, identify technology stacks, and distinguish between validation failures, authorization failures, and non-existent resources. That reduces uncertainty during exploitation and makes it easier to refine attacks against exposed functionality. Error disclosure rarely causes compromise on its own, but it often makes more serious vulnerabilities easier to exploit.
Observable Discrepancy (CWE-203)
Observable discrepancies occur when the application reveals meaningful differences in behavior depending on internal state. The difference may appear in the response body, HTTP status code, timing, or error wording.
In SaaS platforms, these discrepancies often support user, tenant, or resource enumeration. For example, a password reset flow may respond differently for valid and invalid accounts, or an object lookup may reveal whether a record exists even when it should remain undiscoverable. These weaknesses help attackers identify valid targets and prepare more precise attacks against users, tenants, or administrative workflows.
Use of a Broken or Risky Cryptographic Algorithm (CWE-327)
Cryptographic findings in SOC 2 environments tend to involve outdated algorithms, weak cipher suites, insecure protocol choices, or inappropriate use of cryptographic primitives.
For SaaS applications, the impact is not limited to transport security. Weak cryptography can affect session handling, token generation, storage of secrets, or protection of customer data at rest. In practice, this can mean sensitive data is easier to decrypt, tokens are more predictable than intended, or legacy cryptographic settings weaken otherwise mature security controls. In compliance-driven environments, these issues are especially relevant because encryption may exist, but not at the level of assurance the control is meant to provide.
Insufficient Verification of Data Authenticity (CWE-345)
CWE-345 reflects failures to properly verify whether data, tokens, requests, or assertions can be trusted.
In SaaS systems, insufficient authenticity checks can allow attackers to tamper with application state, replay trusted-looking requests, or abuse integration points between services. If the application accepts data at face value without verifying its origin and integrity, attackers may be able to bypass intended workflows or inject untrusted state into account actions, billing flows, or tenant-scoped operations.
URL Redirection to Untrusted Site (‘Open Redirect’) (CWE-601)
Open redirects are often underestimated, but they remain relevant in SOC 2 environments because of how commonly SaaS platforms rely on login flows, invitation links, identity-provider redirects, and multi-step onboarding journeys.
An open redirect allows attackers to abuse a trusted application domain to send users to a malicious destination. On its own, that may seem minor. In practice, it can support phishing, token theft, or redirection attacks against users who trust the platform’s domain. In SaaS products where identity and account access are central, redirect flaws can become part of more effective credential-harvesting or session theft scenarios.
Insufficient Session Expiration (CWE-613)
Session management weaknesses remain highly relevant in authenticated applications. CWE-613 covers situations where sessions remain valid longer than they should, are not invalidated when account state changes, or persist after logout or credential changes.
For SaaS applications, weak session expiration increases the value of stolen or leaked session material. A compromised browser session, shared workstation, or intercepted token may continue to provide access long after it should have been invalidated. In multi-user administrative environments, CWE-613 can expose billing, customer data, operational settings, or administrative controls to unauthorized users.
Authorization Bypass Through User-Controlled Key (CWE-639)
CWE-639 is particularly important in API-driven SaaS systems. It occurs when access to a resource is determined by a user-controlled identifier — such as an account ID, invoice ID, document ID, or tenant reference — without verifying that the requester is authorized to use that identifier.
In practice, this is one of the clearest ways customer data isolation fails. Attackers modify an object reference in a request and retrieve or manipulate another customer’s data because the backend trusts the identifier without enforcing ownership. In SOC 2 environments, this type of flaw is especially serious because it directly undermines one of the most important security expectations in SaaS: that one customer cannot access another customer’s resources.
Protection Mechanism Failure (CWE-693)
Protection mechanism failure is a broad category, but in SOC 2 testing, it often reflects a familiar pattern: teams implemented controls, but they don’t behave consistently across the application.
In SaaS systems, this may include missing checks on specific endpoints, inconsistent enforcement of role restrictions, bypassable validation layers, incomplete hardening, or reliance on frontend restrictions without equivalent backend controls. These weaknesses matter because they create gaps between the intended security model and the actual enforcement model.
Why These Findings Matter in SaaS Environments
Taken together, these CWEs describe the kinds of failures that matter most in SOC 2-scoped applications. They are not primarily about unauthenticated compromise of obviously exposed systems. More often, they reveal how a legitimate account, a trusted workflow, or a partially protected application component can be abused in ways that violate tenant isolation, expose sensitive data, or bypass intended controls.
That is why SOC 2 penetration testing so often surfaces issues inside authenticated areas of SaaS applications. Authentication may be present, and perimeter controls may be in place, but the real question is whether the application consistently enforces trust boundaries once a user is already inside.
Primary Attack Vectors in SOC 2 Penetration Testing
One of the most important observations from SOC 2 penetration testing engagements is that many vulnerabilities involve authenticated users rather than unauthenticated attackers.
As shown in the chart above, the largest share of findings involves authenticated users abusing permissions within the system. This category represents approximately 38% of identified vulnerabilities.
This pattern reflects the nature of modern SaaS and enterprise applications. Authentication mechanisms are often implemented correctly, but authorization logic may not consistently enforce what users are allowed to do once they are logged in. Common scenarios include manipulating object identifiers in API requests to access another user’s data, bypassing role restrictions, or performing operations that should require elevated privileges.
The second largest group of findings involves information leakage and reconnaissance-related vulnerabilities, accounting for roughly 25% of issues in SOC 2 assessments. These weaknesses expose information that helps attackers understand system behavior and identify further attack opportunities.
Roughly 14% of SOC 2 findings involve session or token abuse, highlighting the importance of secure session lifecycle management in authenticated SaaS environments.
Another notable share of findings, about 13%, relates to cryptographic or protection weaknesses, where controls exist but do not provide the intended level of assurance in practice.
What SOC 2 Penetration Tests Reveal About Modern Application Security
The vulnerabilities uncovered during SOC 2 penetration tests provide insights into how security controls behave under adversarial conditions.
In many organizations, baseline security controls such as encryption, authentication, and perimeter protections are already in place. As a result, penetration tests rarely uncover completely exposed systems or missing security controls.
Instead, the most common vulnerabilities emerge inside trusted application boundaries. Security mechanisms may exist, but are implemented inconsistently across different services or endpoints. Authorization checks may vary between APIs and user interfaces. New application features may bypass established security patterns.
These weaknesses are difficult to detect through automated tools or vulnerability scanning alone and typically become visible only when systems are examined through adversarial testing that analyzes real application workflows.
Many of these patterns also appear outside compliance-driven assessments; for a broader view, see our article on common penetration testing findings.
Conclusion
While SOC 2 requirements don’t explicitly mandate penetration testing, offensive security testing is commonly used to support the Trust Services Criteria. Penetration testing often complements the broader risk assessment process by not only identifying potential vulnerabilities but also showing how they behave under adversarial conditions.
Additionally, far from focusing only on technical exploits, pentests frequently uncover practical issues in how applications enforce access control, manage user permissions, and handle sensitive data. Many of these issues arise within authenticated areas of applications, where legitimate users can interact with systems in ways that were not anticipated during development.
Demonstrating effective security controls is a crucial part of meeting SOC 2 compliance objectives. By identifying complex vulnerabilities, assessing control effectiveness and providing remediation insights, SOC 2 penetration testing helps demonstrate that organizations have correctly implemented robust security measures.
