Key takeaways

• The OWASP Top 10 update for 2025 is mostly a consolidation of the previous edition with some adjustments and priority shifts but no major changes.
• Broken Access Control is still the #1 application security risk category and now also incorporates SSRF (previously a separate category).
• Security Misconfigurations and Software Supply Chain Failures have both climbed into the top 3, reflecting the growing prevalence of these attack vectors.
• Mishandling of Exceptional Conditions is the only completely new category.
• The current top 3 are a reminder that software composition and setup are now a critical part of the wider application security picture.

The OWASP Top 10 2025 at a glance

• A01:2025 – Broken Access Control (no change, now includes SSRF)
• A02:2025 – Security Misconfiguration (↑ 3)
• A03:2025 – Software Supply Chain Failures (↑ 3, expansion of Vulnerable and Outdated Components)
• A04:2025 – Cryptographic Failures (↓ 2)
• A05:2025 – Injection (↓ 2)
• A06:2025 – Insecure Design (↓ 2)
• A07:2025 – Authentication Failures (no change)
• A08:2025 – Software or Data Integrity Failures (no change)
• A09:2025 – Logging & Alerting Failures (no change)
• A10:2025 – Mishandling of Exceptional Conditions (new)

OWASP Top 10 methodology

The OWASP Top 10 is updated every four years by the Open Web Application Security Project. It provides a high-level grouping of security weaknesses (CWEs) that are most prevalent in real-world web applications, based on contributed test data and CVEs. While the list originally started as a list of top security flaw types, the 2025 update continues the shift towards highlighting root causes more than their symptoms (i.e. specific vulnerabilities). In fact, the only “symptom” category remaining in the 2025 edition is Injection, mostly because there can be so many different causes of different injection vulnerabilities.

The data inputs for the project include security testing results from project contributors as well as a community survey to identify important risk categories that might not show up in the test dataset. For the 2025 edition, the two categories – included and ranked based on the survey rather than test data alone – are Software Supply Chain Failures and Logging & Alerting Failures.

OWASP Top 10 2025 category analysis

The authors clearly note that categorizing CWEs is by far the hardest part of OWASP Top 10 work and that some overlaps are inevitable, especially with the shift towards isolating root causes (of which there could be more than one). The top 10 categories are deliberately high-level and intended to drive awareness rather than serve as a testing checklist. A few of the categories are not directly testable at all, notably Insecure Design.

A01:2025 – Broken Access Control

The #1 application security risk category hasn’t budged since the previous edition and is also a long-time member of the OWASP Top 10. This time, Broken Access Control covers 40 separate security issues that may in some way allow malicious actors to access data, resources, user accounts, or operations that shouldn’t be accessible to them. 

Example CWEs include some avenues of sensitive information exposure, direct data access via path traversal or forced browsing, missing or incorrect authorization, open redirects, and improper storage of sensitive data. Perhaps a little controversially, server-side request forgery (SSRF) is now also included here as a type of access control issue rather than a separate category (as in the previous edition). This inclusion alone should keep the #1 spot unchanged for a long time.

A02:2025 – Security Misconfiguration

Another perennial top 10 member, security misconfigurations have been climbing ever higher with each recent edition, now jumping up three places since 2021. This is hardly surprising since the authors note that “100% of the applications tested were found to have some form of misconfiguration.” 

As web applications grow ever more complex and incorporate multiple components across a huge variety of technologies and environments, configuration errors are likely to remain a major security risk in the future. Typical security vulnerabilities that fall into this category include insufficient system hardening, missing or incorrect security headers, and running software with insecure default settings (including default credentials, accounts, and privileges). Also included since 2021 is XXE.

A03:2025 – Software Supply Chain Failures

Supply chain security has been a factor in so many high-profile cyberattacks since 2021, from Log4Shell to MoveIT and more, that a big jump is no surprise for this category. Renamed and broadened since 2021’s Vulnerable and Outdated Components, the category now encompasses more types of supply chain risks. While it’s hard to surface from the CVE data, it was ranked the #1 security risk by half of the community survey participants.

Invicti CISO Matthew Sciberras was not surprised to see this category move into the top 3: “As expected, supply chain vulnerabilities have moved further up in the OWASP Top 10, reflecting the reality we've been witnessing across the industry. The increasing interconnectedness and reliance on third-party components have expanded the attack surface in ways that make supply chain risk impossible to ignore. We’re seeing sophisticated adversaries exploiting dependencies, integrations, and vendor relationships, so I had no doubt this shift would occur. It's a clear signal that organizations must extend their security visibility and resilience strategies, beyond their own perimeter, to include the entire ecosystem they depend on.”

A04:2025 – Cryptographic Failures

Dropping slightly in this edition is a catch-all category for plaintext sensitive data exposure, especially sensitive data such as access keys and credentials. The category includes 32 weaknesses related to all aspects of data encryption, from using only secure and suitable algorithms to applying them in all the right places and managing encryption keys securely.

The word “cryptographic” in the category name serves as a reminder that encrypting all sensitive data in transit and at rest is now non-negotiable. An obvious if simplistic example is using HTTP Strict Transport Security (HSTS) to ensure that all traffic to and from a web application is encrypted to prevent data exposure and session hijacking attacks. Another common security failure from this category is the use of weak hashing algorithms or unsalted hashes, which leaves applications vulnerable to brute-forcing by attackers with ever more computational power at their disposal.

A05:2025 – Injection

Since 2021, the Injection category is where all the previously separate injection weaknesses live, covering SQL injection, cross-site scripting (XSS), command injection, and more. It’s now the only risk category defined more by symptoms than root causes, although its 37 component CWEs are mostly various flavors of improper input neutralization or validation.

Injections have historically been near the top of the list but have been gradually slipping down in recent editions, and with good reason. While the selection and ordering of prevalent injection weaknesses change as web technologies evolve, doing proper validation, sanitization, and encoding is always a must. The best way to prevent injection vulnerabilities is to separate code from data using dedicated interfaces, parameterized queries, and similar constructs. This kind of separation is now standard across many of the popular application frameworks, which explains the relatively lower profile of injection risks in the top 10.

A06:2025 – Insecure Design

This category joins injections and cryptographic failures in moving two steps down the list. When Insecure Design was first added in 2021, it stirred some controversy as the first non-testable Top 10 category. It covers security flaws caused by errors or omissions in application design and architecture, and its presence highlights that some decisions affecting security are made already at the design stage. For example, if a system design doesn’t include fine-grained user management, it’s hard to expect secure role-based access control in the resulting application.

The authors make a point of separating insecure design from insecure implementation. Security Top 10 lists are necessarily focused on analyzing what went wrong with the implementation, so pulling out design as a separate consideration helps to shift some of that focus to decisions made at earlier stages. The Insecure Design category includes 39 CWEs corresponding to design choices that can affect security downstream. The authors stress that both are equally important: “A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation.”

A07:2025 – Authentication Failures

This category is the first of three that are holding steady since the previous edition, with just a name tweak (used to be Identification and Authentication Failures). It is closely related to the current #1 category of Broken Access Control but focuses specifically on user authentication flaws such as weak or missing passwords and various ways to bypass authentication altogether. Broken Access Control, in contrast, is about authorization failures that occur after a user is authenticated.

The 36 CWEs in this category overlap with many familiar IT security risks such as password reuse, failure to use multi-factor authentication, excessive user session time-outs, and use of default credentials in production. Authentication is step one of access control and unless it’s implemented securely, all the steps built on top of it are at risk.

A08:2025 – Software or Data Integrity Failures

Remaining at #8 and closely related to supply chain security flaws are software and data integrity failures, in which your application uses code or data without checking whether it’s been tampered with. The SolarWinds attack from 2020 is a high-profile example of failing to ensure software integrity, with malicious code being covertly inserted into a repository and eventually deployed in production. The 14 CWEs within this category include insecure deserialization, where stored data from untrusted sources (or trusted data stored after serialization) is loaded and used without verification.

The authors clarify that this category is about the “failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts at a lower level than Software Supply Chain Failures.” So while supply chain security looks at components and dependencies, ensuring software and data integrity requires checking if the actual bits you’re working with are what you expect, do what you think they do, and haven’t been tampered with. 

A09:2025 – Logging & Alerting Failures

This is another OWASP Top 10 regular (renamed from Security Logging and Monitoring Failures) and the second hard-to-test category that’s included based on the community survey. It’s crucial for operational security because without activity logs and suitable alerts, you have no way of promptly detecting suspicious operations, so the only way to tell if you’ve had a breach is for someone to discover it by accident. While cybersecurity news tends to present attacks and breaches as hit-and-run events, many compromises are persistent and can remain undetected for months or even years without proper security logging and alerting. One of the CWEs covered is specifically about insecure log processing that may allow attackers to use logs as an attack vector or modify them to cover their tracks.

Again, risks from this category are hard to test for because they’re all about incidents that weren’t recorded. However, they can have serious and measurable compliance consequences, especially for reportable breaches that involve other sensitive data. This is likely why the category continues to rank high in the community survey. The last thing any CISO wants is to learn about a data breach in their company from the news.

A10:2025 – Mishandling of Exceptional Conditions

This is the only new entry in the OWASP Top 10:2025 and covers a wide variety of security flaws related to error handling that may either reveal information to attackers or allow them to predictably trigger error conditions as part of an attack chain. Getting an application to crash or misbehave is often the first reconnaissance step for attackers and pentesters looking for a way in.

The most common example would be excessively detailed error messages that reveal internal system or program information to the attacker. These can include database column names returned in a SQL error message or a full stack trace displayed after an application crash caused by an uncaught exception. “Leaky” exception handling may allow attackers to trigger certain behaviors or bypass security checks by supplying unexpected data inputs. 

Testing for OWASP Top 10 vulnerabilities

With each subsequent edition, the OWASP Top 10 deliberately moves further away from being a security testing checklist and towards presenting a more strategic overview. Several of the risk categories are now specifically not intended to be testable, or at least aren’t easy to test, which begs the question: what is this list for?

The short answer is that the OWASP Top 10 is now squarely a high-level awareness document – a list of application security areas that you should be aware of at various stages of the software lifecycle. With a total of 589 CWEs analyzed and 248 of those mapped to the resulting categories, it would be impossible to actually test for all of them, especially as not every CWE itself is testable (good luck devising a meaningful test for “Excessive Attack Surface”).

And yet… People talk every day about “testing for OWASP Top 10” because it’s a convenient shorthand for checking all the common and testable high-impact weaknesses. That doesn’t mean you’re also scanning for more abstract weaknesses like CWE-656 Reliance on Security Through Obscurity or CWE-221 Information Loss of Omission. It does, however, mean you should be testing for everything within the OWASP Top 10 that can practically be tested.

Conclusion: Evolution rather than revolution

The software world has changed dramatically since the first edition of the OWASP Top 10 in 2003. Back then, serious web applications were only just appearing, and web application security was in its infancy. Today, web security is foundational for businesses and entire economies, so it’s no longer enough to point out a handful of common vulnerabilities to check.

The only way to get security under control is to embed it into every stage of software design, development, testing, and operations. With its mix of design, implementation, testable, and non-testable security risks, this is exactly how the OWASP Top 10 is evolving. The new top 3 is a clear reminder that with the massive scale and complexity of application environments, configuration and composition are now as important for security as the code itself.