OWASP Top 10 2025 vs 2021: What Has Changed?

The OWASP Top 10 2025 Release Candidate (RC) has the capacity to be a watershed moment in application security. Though not yet finalized, this eighth edition heralds a decisive transition from a vulnerability-centric view to a risk-resilience AppSec model.

Announced in November 2025, the update arrives when cloud-native architectures, microservices, and the software supply chain are paradoxically both the greatest strength and the greatest liability of the software ecosystem.

Reflecting this reality, the most critical changes from 2021 include the debut of A03: Software Supply Chain Failures and A10: Mishandling of Exceptional Conditions. In a similar vein, A02: Security Misconfiguration has climbed dramatically from fifth to second place, showing that complexity is now a key adversary.

Meanwhile, A01: Broken Access Control keeps its primacy as the top risk. This undesired consistency emphasizes an uncomfortable reality: Authorization logic remains the most fragile and difficult-to-test component of modern web applications.

This article offers a thorough technical analysis of the OWASP Top 10 2025 vs. 2021. In addition to the changes in the list itself, you will learn:

• New imperatives for CISOs, engineering leads, and business executives
• The relationship with OWASP API Security Top 10 (OWASP, 2023)

Comparative Analysis: Structural Development from 2021 to 2025

The Top 10 hierarchy has changed to match the dynamic nature of software development. More specifically, the new list mirrors the move towards shift left and the growing reliance on third-party code.

This table summarizes the changes between the OWASP Top 10 2021 and 2025 editions, providing a high-level overview of the current tendencies:

A01 Broken Access Control: The Persistent Sovereign

Broken Access Control (BAC) remains the single most critical security risk facing web applications.

Unlike injection vulnerabilities—which static syntax analysis may flag through patterns such as unsafe constructors—access control flaws are deeply contextual. A tool cannot easily determine if User A should have access to Record B. Only the business logic and the specific domain requirements dictate that entitlement.

Consolidating SSRF into A01 reflects an expanded interpretation of access control. This interpretation encompasses trust boundary violations (“Should this server-side request be permitted at all?”) as well as authorization failures (“Can this user access this resource?”). The common thread is unauthorized access to resources, whether they are another user’s data or an internal network endpoint.

That said, the consolidation feels somewhat forced from a practitioner’s perspective.

In real-world engagements, SSRF and BAC have distinct exploitation patterns, impacts, and remediation strategies. SSRF typically chains into cloud metadata theft (the classic http://169.254.169.254/latest/meta-data/ on misconfigured cloud instances), internal service discovery, or protocol smuggling rather than traditional authorization bypasses.

You are rarely exploiting SSRF to access another user’s invoice; you are pivoting to infrastructure.

From a defensive standpoint, the mitigations diverge entirely: BAC requires authorization logic, RBAC enforcement, and ownership validation at the application layer. SSRF demands egress filtering, URL allowlisting, and infrastructure controls like IMDSv2.

Notably, CSRF (CWE-352) still appears in this category’s CWE mappings, though its practical relevance has diminished significantly. Modern browsers default to SameSite=Lax for cookies, blocking cross-origin POST requests from carrying session credentials.

Contemporary CSRF exploitation now requires either explicit SameSite=None configurations—typically for legitimate cross-origin integrations—or same-site gadget chains, substantially narrowing the attack surface compared to the pre-2020 landscape.

This is precisely why BAC tops the list yet remains chronically under-tested.

Traditional SAST tools can’t model authorization logic, and conventional DAST scanners lack the authenticated, multi-role context needed to detect privilege escalation. Testing whether User A can access User B’s resources requires tooling that:

• Understands your API’s authentication scheme
• Can impersonate multiple principles
• Systematically probes object-level access

And that is something that demands purpose-built API security testing, not generic vulnerability scanners.

A02 Security Misconfiguration: The Complexity Tax

The ascent of Security Misconfiguration from the fifth to the second position is a direct consequence of the industry’s transition toward cloud-native, highly configurable environments. It implies that environmental security is becoming exponentially more complex, or maybe deteriorating, even as code security itself might be improving through better frameworks.

This category covers a wide range of security weaknesses that occur not in the code itself, but in the environment that hosts it:

• Unpatched platforms: Outdated operating systems, frameworks, and libraries
• Cloud exposures: Open AWS S3 buckets, overly permissive IAM roles, and exposed management interfaces
• HTTP headers: Missing or misconfigured security headers, such as Content Security Policy (CSP)
• Default credentials: Default accounts and passwords present in production systems or third-party appliances
• Container orchestration: Improperly configured permissions in containerized environments like Kubernetes and Docker, such as allowing containers to run as root or without proper isolation
• XML parsing: Enabled XML external entity (XXE) processing in parsers, a legacy default that persists in many enterprise stacks

The shift-left movement has placed greater responsibility for infrastructure on developers. Unfortunately, since this has not traditionally been their primary concern, they may lack the security expertise to configure complex cloud IAM roles or network policies.

Consequently, this democratization of infrastructure management has statistically increased the risk of misconfiguration.

The challenge with misconfiguration is its sprawl: It spans infrastructure, runtime, and application layers, each with its own configuration surface.

Point-in-time audits, such as quarterly penetration tests or annual compliance scans, cannot keep pace with the velocity of infrastructure changes in CI/CD pipelines. Detecting security misconfigurations at scale requires continuous, automated testing that can evaluate configurations as they’re deployed, not months after the fact.

A03 Software Supply Chain: The Uncharted Terrain

This ranking is arguably the most significant structural change in the 2025 release. And the security community agrees: 50% of survey respondents ranked it as their top concern, which is the highest level of consensus across any category.

In 2021, A06 concentrated on software components with confirmed CVEs. The 2025 update rebrands and expands it to Software Supply Chain Failures, acknowledging that the risk extends beyond vulnerable code to the integrity of acquisition, build, and distribution processes themselves.

Notably, traditional vulnerability tracking struggles here. Despite having the highest average incidence rate—5.19% (OWASP, 2025)—only 11 CVEs are mapped to this category. Supply chain compromises often evade the CVE model entirely; they’re not bugs in code, but trust failures in processes.

This category now encompasses:

• Dependencies: Third-party libraries and frameworks (the traditional scope)
• Transitive dependencies: The libraries your libraries depend on, often dozens of layers deep, where a single compromised package like event-stream or colors.js cascades across thousands of projects
• Build systems: CI/CD pipelines such as Jenkins are now prime targets, as seen in the SolarWinds Orion attack (The MITRE Corporation, 2025)
• Distribution infrastructure: Package registries, like npm and PyPI, and container registries, where attackers trick build systems into pulling malicious public packages instead of internal private ones
• Chain of custody: Artifacts not verified through signing and provenance mechanisms such as SLSA or SBOMs, which leaves organizations vulnerable to tampering

Traditional SAST and SCA tools can flag known CVEs in direct dependencies. However, verifying build pipeline integrity, detecting dependency confusion attacks, or validating artifact provenance requires a different approach. An approach that treats the entire delivery pipeline (not just the application code) as an attack surface.

A04 Cryptographic Failures: The Legacy Burden

Previously known as Sensitive Data Exposure (2017), renamed to Cryptographic Failures in 2021, this category slides two spots in 2025.

This descent does not necessarily mean that cryptography has become less important. Instead, it suggests that other risks (Misconfiguration and Supply Chain) have become more volatile and prevalent.

CPU-level AES acceleration eliminates performance gaps, and services like Let’s Encrypt have commoditized certificate management. The persistent failures are due to legacy debt.

The category continues to address critical oversights in guaranteeing data confidentiality:

• Weak algorithms: Use of deprecated algorithms—MD5, SHA1, or RC4—vulnerable to collision or brute-force attacks
• Insufficient entropy: Weak pseudo-random number generators (PRNGs) or predictable seeding (three of the top CWEs in this category relate to randomness failures)
• Hardcoded secrets: Storing cryptographic keys or passwords in the source code
• Transmission security: Neglecting to enforce encryption in transit (TLS 1.2+) or accepting weak cipher suites
• Key management: Improper key generation, rotation, or storage
• Protocol downgrade: Configurations that allow attackers to force weaker cipher suites or protocol versions

A05 Injection: The Decline of Syntax Errors

Once the perennial #1 risk (A01 in 2017 and prior), Injection continues its gradual decline in ranking.

The drop to #5 in 2025 reflects the success of modern application frameworks and techniques, such as React, Angular, Vue, and modern object-relational mappers (ORMs). They handle output encoding and query parameterization by default, which substantially reduces the attack surface for classic SQL injection and reflected XSS.

With 62,445 CVEs, Injection leads the count. This figure indicates that the decline in its vulnerability ranking reflects reduced exploitability, not reduced presence.

Today, Injection includes:

• SQL injection: A risk in legacy applications or when developers bypass ORM protections, such as through raw SQL queries
• Command injection: An unsanitized user input passed to system shells, allowing attackers to carry out arbitrary commands
• Cross-site scripting: Both stored and DOM-based XSS, especially in complex single-page applications (SPAs) that manipulate the Document Object Model directly
• LDAP/NoSQL injection: A vulnerability in modern applications using LDAP or NoSQL databases, where unsanitized input manipulates database queries or commands
• Prompt injection: A new entrant acknowledged via the OWASP LLM Top 10, it involves manipulating LLM inputs to bypass instructions or exfiltrate data, thereby extending the injection paradigm to AI systems

It’s worth noting that Injection remains a category where vulnerabilities are predominantly identified through manual testing.

Classic SAST tools, burdened by lengthy analysis cycles, often lose context and miss unsanitized inputs in complex codebases. DAST can fuzz individual parameters, but detecting multi-step exploits, where an injection requires chained requests or spans multiple data flows, demands more sophisticated orchestration than traditional scanners provide.

That is precisely where purpose-built API security testing closes the gap. It can:

• Understand the authentication context
• Model multi-request flows
• Systematically probe injection points across GraphQL resolvers, serverless functions, and emerging surfaces like LLM prompts

These are all attack vectors that legacy tooling simply wasn’t designed to cover.

A06 Insecure Design: The Architecture Gap

Insecure Design dropped from fourth to sixth position, but it remains a persistent web application security risk. Introduced in 2021, it focuses on risks arising from design and architectural flaws, thereby advocating Secure by Design principles.

This category includes risks that a simple code patch cannot fix because they are inherent to the system’s workflow or business logic. Examples include:

• Inadequate or missing rate limiting: Insufficient controls against brute forcing or credential stuffing
• Business logic flaws: Purchase flows that allow checking out with negative prices or bypassing payment steps
• API exposure: Internal APIs exposed publicly due to architectural oversight
• Trust boundary violations: Accepting client-side data without server-side validation, or failing to re-authenticate for sensitive operations
• Unrestricted file uploads: Allowing dangerous file types without content validation, which is a design decision rather than an implementation bug

The remediation for A06 requires threat modeling during the design phase. This practice is gaining more traction but is still far from universal. It underlines that security cannot be “tested in” at the end; it must be “designed in” from the outset.

Testing plays a crucial role in validating secure design assumptions. Automated API security testing can systematically verify that:

• You have enforced rate limits
• Business logic flows reject invalid state transitions
• Tenant boundaries hold under adversarial conditions

In other words, it turns design requirements into continuously validated controls.

A07 Authentication Failures: Identity at Risk

With its ranking unchanged and slightly renamed from Identification and Authentication Failures in 2021, this category addresses weaknesses in user identity validation and session management.

The stability of its ranking shows that, despite identity providers like Okta and Auth0 reducing developers’ burden, custom authentication implementations remain prone to errors.

Common authentication vulnerabilities include:

• Credential stuffing and password spraying: Attackers no longer replay breached credentials; they now use hybrid attacks, trying variations like “Password1!,” “Password2!,” “Password3!,” and so on against known usernames
• Lax password rules: The organization allows users to pick easily guessable passwords or keep default ones

• Insecure resets: The “Forgot Password” process is too flimsy, giving attackers an easy backdoor into accounts
• Session handling: Session fixation, tokens that survive logout, or session IDs exposed in URLs—all failures that let attackers hijack authenticated sessions
• No multi-factor authentication (MFA): Critical accounts are left exposed because there is no second step to verify identity
• Certificate validation failures: APIs that don’t properly validate TLS certificates, enabling man-in-the-middle attacks against authentication flows

Authentication endpoints are prime targets for automated attacks, making them ideal candidates for continuous security testing. Verifying that rate limits trigger correctly, session tokens rotate after login, and logout actually invalidates server-side state simply calls for systematic, repeatable testing.

A08 Software or Data Integrity Failures: The Trust Boundary Violation

The name and ranking of this category stay unchanged. It revolves around security weaknesses arising from making assumptions about software updates, critical data, and CI/CD pipelines, but failing to verify their integrity.

Unlike A03 Software Supply Chain Failures, which addresses compromises upstream in your dependencies and build systems, A08 focuses on integrity failures within your environment. Unauthorized changes, tampered artifacts, unsigned binaries, and unverified data, even when the supply chain itself is intact, are all part of this category.

More precisely, it includes vulnerabilities such as:

• Insecure deserialization: Converting untrusted data, like a cookie or JSON blob, back into an object without validation, which can allow remote code execution
• Untrusted updates: Downloading updates without verifying digital signatures
• Object modification: Improperly controlled change of dynamically-determined object attributes
• Inclusion from untrusted sources: Loading functionality from CDNs, third-party scripts, or external services without integrity validation (a single compromised CDN can inject malicious code into thousands of applications)
• Unverified CI/CD artifacts: Build pipelines that deploy binaries without signature verification, allowing tampered artifacts to reach production

These failures are particularly insidious because they rarely cause functional errors. The application still works, but it now operates on the attacker’s terms. For instance, a compromised config file that quietly enables debug endpoints. Or a tampered serialized object that grants elevated privileges.

A09 Logging & Alerting Failures: The Silent Flop

Retaining its position, this category reminds us that security breaches are inevitable and failing to detect them is a critical risk. As OWASP itself puts it, “Great logging with no alerting is of minimal value” (OWASP, 2025).

The category of Logging & Alerting Failures covers:

• Insufficient logging: Neglecting to record critical transactions, such as failed login attempts and high-value transfers
• Log integrity: Allowing logs that are not backed up or that attackers can overwrite to hide their tracks
• Lack of alerting: Missing real-time alerts on suspicious thresholds, like 100 failed logins in 1 minute
• Sensitive data in logs: Inadvertently logging PII, credentials, or tokens, creating a secondary breach vector when logs are exposed (CWE-532)
• Log injection: Failing to encode log output, which allows attackers to forge entries or exploit log processing systems (CWE-117)
• Alert fatigue: Too many false positives, which bury genuine threats and leave SOC teams unable to distinguish critical alerts from noise

Security tests must trigger immediate alerts.

If your security team doesn’t receive notifications when a solution like Equixly runs against your APIs, your detection capabilities need urgent improvement.

That implies logging validation is a critical component of security testing. You must not only verify that logs are present, but also that they actively trigger the appropriate response.

A10 Mishandling of Exceptional Conditions: The Resilience Imperative

The introduction of Mishandling of Exceptional Conditions to replace SSRF is the second major novelty of the 2025 list. This category aggregates vulnerabilities stemming from how systems behave under stress, error, or abnormal inputs.

The central theme of A10 is failing open. If an application encounters a database error during an access check and defaults to allowing access, it creates a catastrophic vulnerability (MITRE Corporation, 2025).

What are the key risks in the mishandling of exceptional conditions?

• Verbose error messages: Revealing stack traces, database errors, or internal paths to users (CWE-209 explicitly flags this as attacker reconnaissance fuel)
• Missing parameter handling: Failing to gracefully handle absent or malformed inputs, which leads to undefined behavior (CWE-234)
• Insufficient privilege handling: Inadequate responding when privilege checks fail, potentially defaulting to elevated access (CWE-274)
• Null pointer dereference: Often dismissed as a quality bug, this can lead to denial of service or allow logic bypass if the null state creates an undefined execution path
• Unchecked return values: Ignoring the return status of a critical function and assuming it succeeded when, in reality, it failed

Testing for these weaknesses requires more than happy-path validation.

It demands fault injection, boundary condition testing, and systematic exploration of error states. That means sending malformed inputs, triggering resource exhaustion, and verifying that every failure mode results in a secure, well-defined state rather than silent continuation or privilege escalation.

Strategic Implications for Stakeholders

The changes in the OWASP Top 10 2025 entail different considerations for different roles within an organization, calling for budget, culture, and tooling adjustments.

CISOs and Executives

Budget Reallocation

CISOs must invest in both cloud security posture management and software supply chain security to detect misconfigurations, manage SBOMs, and apply artifact signing.

Resilience as a KPI

With A10 entering the list, “Uptime,” “Error Rates,” and “Recovery Time Objectives (RTO)” become security as well as operational metrics.

Audit and Compliance

The strong emphasis on supply chains will likely lead to stricter audit requirements for third-party vendor assessments. CISOs must be ready to demonstrate the provenance of the software and how it was built, as well as what software their organization operates in production.

Developers and Engineering Leads

Configuration Is Code

Since Security Misconfiguration is a top concern, developers must apply the same level of scrutiny and testing to infrastructure-as-code files—Terraform, Helm charts, and Dockerfiles—as they do to application code in Java or Python.

Error Handling Discipline

Using generic exceptions instead of specific error handling is now considered a poor security practice. This method is risky because it can mask serious security problems, making them hard to find and fix.

Dependency Hygiene

To mitigate A03 risks, developers must verify package integrity, pin versions, and review the origin of the libraries they introduce.

Application Security Engineers

Tooling Gaps

A10 is notoriously hard to scan for with traditional SAST/DAST tools. AppSec teams must invest in fuzzing and other mechanisms that help them identify logic flaws.

Pipeline Security

AppSec responsibilities now extend to the CI/CD pipeline itself. Securing the Jenkins server, the GitHub Actions runners, and the artifact registry is as important as securing the web server.

Threat Modeling

The persistence of Insecure Design requires AppSec engineers to include threat modeling sessions early in the design phase, identifying architectural flaws before developers even write the code.

The Relationship with OWASP API Security Top 10

It is key to distinguish the OWASP Top 10 2025 from the OWASP API Security Top 10 2023. They share the same DNA but are distinct standards created for different contexts.

The main difference is that one focuses on general web applications, and the other on APIs.

This characterization, of course, sounds trivial and uninformative. However, don’t let the triviality conceal the fact that there are two different OWASP projects, one for web applications and another for APIs, for a good reason.

First, this fact speaks loudly of the unique nature of APIs vis-à-vis web applications. Second, it makes clear that understanding the particular security risks APIs face is critical.

How so? The general OWASP Top 10 and the corresponding web application security mechanisms cannot adequately address API security risks, as we’ve seen in practice time and again.

Simplified, security teams should use

• Web Top 10 to assess the frontend application and the monolith
• API Top 10 to evaluate backend services, microservices, and anything exposed via REST, GraphQL, or SOAP

Final Thoughts

The OWASP Top 10 2025 marks an important shift:

• Modern security must be about systemic resilience
• Organizations must move to all-encompassing, architectural risk management
• Application security now means securing the entire software ecosystem, including all aspects of the software supply chain, not just the code
• Teams should shift left and integrate security from the very outset, before the first line of code sees the light of day
• Developers must approach infrastructure-as-code and error handling with the same rigor as access control
• Traditional point-in-time testing is insufficient; continuous, automated security validation is the only way to keep time with the CI/CD’s rhythm

Get in touch to discuss a dedicated API security solution that plays well with your AppSec strategy.

FAQs

What are the most important changes in the OWASP Top 10 2025 Release Candidate?

Software Supply Chain Failures and Mishandling of Exceptional Conditions, reflecting the new challenges posed by third-party dependencies and systemic resilience.

Why did Security Misconfiguration climb dramatically from fifth to second place in the new list?

This jump reflects the increasing complexity and associated risks of cloud-native, highly configurable environments, where infrastructure management is now often the responsibility of developers.

How does the new list address the 2021 SSRF vulnerability?

SSRF has been consolidated under Broken Access Control, as OWASP now sees it as fundamentally an access-control failure in which the server is unauthorized to access an internal network resource.

Alessio Dalla Piazza

CTO & FOUNDER

Former Founder & CTO of CYS4, he embarked on active digital surveillance work in 2014, collaborating with global and local law enforcement to combat terrorism and organized crime. He designed and utilized advanced eavesdropping technologies, identifying Zero-days in products like Skype, VMware, Safari, Docker, and IBM WebSphere. In June 2016, he transitioned to a research role at an international firm, where he crafted tools for automated offensive security and vulnerability detection. He discovered multiple vulnerabilities that, if exploited, would grant complete control. His expertise served the banking, insurance, and industrial sectors through Red Team operations, Incident Management, and Advanced Training, enhancing client security.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.

Eugen Saraci

Security Researcher

Eugen is a curious and passionate security enthusiast. During his years at the University of Padua, he developed a deeper interest in AI and cybersecurity, leading to the publication of both his Bachelor's and Master's theses in renowned venues such as ESORICS and USENIX. After earning his Master's degree, Eugen worked on penetration testing while at a consulting firm, engaging in a range of offensive security activities, from cloud security reviews to traditional web and API penetration tests in the Banking and Telco industries. He also contributed to the creation of security guidelines for Docker, web server configurations, and AI/LLM development.