If you’ve been in Application Security (AppSec) or cyber more broadly, you’ve inevitably heard of the OWASP Top 10. It’s a mainstay within the AppSec community, and as OWASP itself says, it is:

It is a global standard used to raise awareness and educate developers and those in Application Security (AppSec) about the most critical security risks facing web applications.

As part of the OWASP Global AppSec Conference in Washington, D.C., in November, the OWASP Top 10 has just received its most significant update since 2021, and I wanted to dive into some of the key updates and takeaways for the community.

For those interested, there is also an associated slide deck/presentation from the OWASP D.C. event, which covers the updates to the OWASP Top 10.

Interested in sponsoring an issue of Resilient Cyber?

This includes reaching over 40,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives

Reach out below!

-> Contact Us! <-

Bottom Line Up Front

I know most folks have short attention spans and want the bottom line up front (BLUF). What are the significant changes? Those can be summarized in the image below from OWASP:

Some things remained the same, while other significant changes did occur.

On the status quo front, Broken Access Control remains the king of the hill, dominating the top spot in both the 2021 and 2025 versions of the Top 10. OWASP states that 3.73% of applications tested had one or more Common Weaknesses and Enumerations (CWEs) in this category.

A wilder stat is that OWASP states:

“100% of applications tested were found to have some form of broken access control”.

That’s truly astounding.

The presenters at OWASP D.C. noted that this is “hands down” the #1 category for web apps, APIs, and other digital systems. Key aspects of prevention include a deny-by-default approach, centralized AuthZ, rate limiting, and effective monitoring and logging. I suspect this risk will only grow in both occurrence and complexity with the rise of Agentic AI and challenges associated with agentic identity and AuthN/AuthZ, including being tied to the popular Model Context Protocol (MCP).

Some are hopeful that advances in Static Application Security Testing (SAST) are tied to the integration of AI and LLMs due to the ability to examine complex business logic flaws, authentication bypasses, and data flow issues in a way that rule-based traditional SAST tools may miss.

The AI SAST tooling does this through understanding code semantics, data flow, and intent. There has also been early promising research demonstrating that the use of AI SAST can also drastically reduce false positives.

Three risks did, however, move down in ranking, which were:

• Cryptographic Failures - failures related to the lack of cryptography, insufficiently strong cryptography, leaking crypto keys, and related errors.

• Injection - a system flaw that allows an attacker to insert malicious code or commands into a program's input fields, tricking the system into executing the code or commands as if they were part of the system.

• Insecure Design - A broad category of weaknesses, expressed as “missing or ineffective control design”. (not the same as insecure implementation).

OWASP notes that Insecure Design, in particular, has seen notable improvements driven by the increased use of threat modeling, as well as a great emphasis on Secure-by-Design, demonstrating that perhaps not all efforts are virtue signaling pledges, such as some vendors signing CISA’s Secure-by-Design Pledge and organizations may be really investing in both proactive threat modeling, as well as Secure-by-Design principles for products and applications.

We see Security Misconfiguration and Software Supply Chain Failures (replacing “Vulnerable and Outdated Components”) move up into the #2 and #3 spots, respectively.

OWASP defines these as:

• Security Misconfiguration - When a system, application, or cloud service is set up incorrectly from a security perspective, it creates vulnerabilities.

• Software Supply Chain Failures - Breakdowns or other compromises in the process of building, distributing, or updating software, often caused by vulnerabilities or malicious changes in third-party code, tools, or other dependencies that a system relies on.

Security Misconfigurations

Security misconfigurations personally don’t come as a significant surprise, as since 2021 (and prior), we’ve continued to see the rise of incidents, especially in the cloud, related to customer misconfigurations.

What makes this category of risks problematic is that there generally aren’t identifiers associated with them, such as with CVEs for vulnerabilities, and “incorrectly from a security perspective” is incredibly subjective, as there is often business justification or significance for a specific configuration that may be vulnerable, but rational from the perspective of the end users and enterprise.

Organizations often make risk acceptance decisions, either implicitly or explicitly, due to business needs and the need to configure products and applications in a specific manner, even if it means accepting a certain level of risk.

It’s also further complicated by the fact that secure configurations (e.g., CIS Benchmarks, DISA STIG’s etc.) don’t always exist for a large portion of products in the market, especially newer and/or less widely adopted products, coupled with a lack of vendor guidance on what a secure configuration looks like. All of this is exacerbated, as OWASP notes, by the increasingly complex digital environments in which we operate.

The presenters from OWASP D.C. noted this includes leaked credentials, which are the top security misconfiguration, and that security misconfigurations are the #1 category for cloud and infrastructure security in particular.

This shouldn’t be surprising, as over the last several years, we’ve seen many high-profile cloud security incidents tied to customer misconfigurations, as well as challenges with identity security, including Non-Human Identities (NHIs) in the cloud, which I’ve written about in prior articles, such as:

• What Are NHI’s and Why Do They Matter?

• The State of NHI Security

• OWASP NHI Top 10 - Juggling NHI Risks

OWASP recommends prevention techniques such as regular hardening, regularly checking configurations, utilizing credential scanners (e.g., for exposed secrets), and disabling unnecessary features.

This last point is something CISA has tried to champion, with its “Secure-by-Default” language, where it advocates for products to come hardened, rather than having hardening left to end users, and products coming with “loosening” guides rather than “hardening” guides.

That said, until there is widespread industry change, hardening will remain the responsibility of end-user organizations, which is why this risk rightly remains one of the primary items on the OWASP Top 10.

Software Supply Chain Failures

I’m admittedly biased in terms of being excited to see this new entry on the Top 10, given I wrote a book entirely focused on software supply chain security titled “Software Transparency: Supply Chain Security in an Era of a Software-Driven Society”.

The software supply chain landscape has become increasingly challenging, not only due to malicious actors targeting both open-source components and projects, as well as widely adopted commercial vendors, but also due to the entire ecosystem, as OWASP itself notes, encompassing build systems, distribution infrastructure, and more.

On that front, OWASP even has its project titled “Secure Pipeline Verification Standard (SPVS)”, which is a “comprehensive, security-focused framework designed to assess, enhance, and standardize the security maturity of software delivery pipelines.

Adding even more complexity to this space is the rise of LLMs, AI, and Agentic Coding Assistants. AI has and is continuing to transform the modern SDLC and software development landscape.

That brings with it various software supply chain risks as well, such as LLMs hallucinating packages, which subsequently get “slopsquatted” by malicious actors, and producing insecure code, often with outdated and vulnerable components from the open-source ecosystem.

Most recently, we have also seen the rise of vulnerabilities and incidents targeting leading AI coding assistants, such as Cursor, Windsurf, and Claude, among others, making these new development companions part of the ever-growing software supply chain attack surface and targeting those who contribute to it—developers.

Closing Thoughts

While this is far from an exhaustive examination of the new OWASP Top 10, I wanted to share some thoughts on the more significant changes in terms of categories, rankings, and industry context for the findings.

I strongly recommend reading the full OWASP Top 10, as each category includes detailed descriptions, score tables, mitigation recommendations, and more. The OWASP Top 10 has been and continues to be an absolute staple of the AppSec community, providing a framework for developing a more secure and resilient digital ecosystem.

I’m incredibly thankful to the contributors and lead authors, and I hope that folks found this brief blog discussing some of the key findings and changes helpful.

As the OWASP Top 10 page itself says, the Top 10 is just the starting point, not the destination.

As I like to say, security is a process, not a product - a discipline, not a destination