OWASP Top 10 2025: Are We Solving the Wrong Problems?

It’s no longer news that The Open Web Application Security Project (OWASP) has released the 2025 Release Candidate of its Top 10 security risks, the eighth edition of the industry’s most-referenced awareness list.

And as expected, the security industry did what it always does: acknowledge the list, share the infographics across their networks, and promise to do better. Then everyone moves on to use the list as a convenient benchmark for “secure” software.

When the eighth edition of the OWASP Top 10 came out on November 6, I started really thinking about what these lists mean. Not what they say they mean but what they actually tell us about how we build software.

Because if everyone knows about these risks, if every security training covers them, if every vendor claims to solve them... why do they keep showing up?

Let me show you what I mean.

What if the persistence of these vulnerabilities isn't a failure of awareness, but a signal that our security model is fundamentally misaligned with how modern software is actually built?

A01 at #1 for Years: Definition of Insanity?

Broken Access Control moved up from fifth position in 2017 to the first position in 2021. It’s been in the top spots for almost a decade. The 2025 data shows 3.73% of applications tested had one or more access control vulnerabilities.

If awareness worked, wouldn't this have moved by now?

Here's what I think: Modern applications are now inherently more complex. We've gone from monolithic apps with simple role checks to distributed systems with microservices, APIs, mobile clients, IoT devices, and edge computing. Authorization in 2025 is not checking if user.role === 'admin' anymore. It's now orchestrating permissions across dozens of services, each with their own context, using JWTs, OAuth flows, and zero-trust architectures.

“Maybe the problem is not that developers don't know about access control. Maybe authorization is genuinely harder in distributed systems, and we're fighting entropy itself.”

Consider this as I have: every new service endpoint is a potential access control failure point. Every API integration multiplies the attack surface. Are we expecting perfection in a domain where the complexity grows exponentially while our tools remain linear?

Is some baseline level of access control issues simply unavoidable at the scale we operate today? What are your thoughts?

A03 Software Supply Chain Failures.

Developers aren’t failing the supply chain; the supply chain is failing developers. And you’ll see why I said this in a minute.

Software Supply Chain Failures expands on the 2021 category "Vulnerable and Outdated Components," covering the full software ecosystem. Everyone "knows" supply chain is risky now. Security Twitter won't shut up about it.

Yet in September 2025, attackers compromised 18 npm packages with over 2.6 billion weekly downloads combined. npm saw more than 184 billion package downloads per month by the end of 2023.

Stay with me. The average JavaScript project depends on hundreds of packages. Each package has its own dependencies called (transitive dependencies). A typical React app might pull in 1,000+ packages when you flatten the dependency tree. Now multiply that across every project your organization maintains.

Developers can't verify every dependency. It's economically impossible.

Reading and auditing 1,000 packages with many written in languages you don't know well, with codebases ranging from 100 to 100,000 lines would take months per project. And you'd need to do it again every time you update. No team has that budget. No business model supports that timeline.

OWASP recommends we verify dependencies, but with thousands of transitive packages, even automation can’t catch everything. At the scale of modern applications, these recommendations may be fundamentally misaligned with how software is actually built and deployed in 2025.

What if the solution is not "be more careful" but "fundamentally redesign package ecosystems"? Maybe we need:

• Cryptographic signing as mandatory, not optional

• Package maintainer insurance requirements for critical dependencies

• Automated formal verification for common dependency patterns

• A complete rethinking of how we model trust in the supply chain

Because right now, we're asking developers to solve a systemic architecture problem, don’t you think?

A10 (Error Handling): Wait, This Is New?

Exception handling was pioneered by PL/I in the 1960s and became popular in many languages from the 1980s onward.(Louden, Programming Languages: Principles and Practice). We've known about proper error handling for literally decades.

But in OWASP 2025, it gets its own category. Why?

Two possibilities I could come up with:

1. Acknowledging a historical blind spot. For 20+ years, the OWASP Top 10 has focused on the “most critical risks,” sometimes overlooking fundamental programming practices that can lead to real-world failures. From catastrophic software crashes to incidents like the 1996 Ariane 5 rocket.

2. Reframing risk for modern systems. What was once “bad code quality” is now explicitly framed as a security concern. Today, mishandled exceptions can expose sensitive data or create unpredictable system states. These risks are increasingly relevant.

   Either way, it reminds us: old practices aren’t always followed or understood. If we’re only now spotlighting error handling, how confident can we be that other categories in the Top 10 truly capture the full spectrum of critical modern risks?

The Checklist Trap

Here's the paradox of the Top 10 format: by highlighting 10 risks, do we unintentionally signal that everything else is secondary?

Organizations treat it like a checkbox exercise: "We've addressed the OWASP Top 10! or our security solution aligns with the OWASP Top 10" becomes a badge of honor. But we keep forgetting that security is deeply dependent on your specific architecture, business logic, and threat model.

Does #10 (Mishandling of Exceptional Conditions) get 10% the attention of #1 (Broken Access Control)? In practice, probably less. Yet for certain systems such as medical devices, industrial control systems, improper error handling could be far more critical than access control issues.

The ranking system may be creating a false sense of priority. Your e-commerce platform's biggest risk might not even be on the OWASP Top 10 list. Maybe it's business logic flaws in your checkout process. Maybe it's race conditions in your inventory system. But because those aren't in the Top 10, they don't get budget, neither do they get fixed.

The Real Questions

The OWASP Top 10 remains one of the most influential security documents in the world. Undoubtedly. However, it's important to remember what it actually is: a community-driven awareness list, not a full risk model.

Once we understand this, we can begin to ask bigger questions.

Not "how do we fix the OWASP Top 10?" but "why do these vulnerabilities persist despite massive awareness?" Not "how do we train developers better?" but "how do we build systems that are secure by default?"

The answers might require rethinking fundamental assumptions about how we build, deploy, and maintain software. And maybe we should!

Software in 2025 is nothing like it was when OWASP first published the Top 10 over 20 years ago.
And even though the Top 10 has evolved, the underlying problem remains: we keep seeing the same recurring weaknesses year after year.

So are we trying to patch symptoms instead of addressing structural issues?

Because maybe the real challenges today is that:

• Our systems are so complex that traditional security processes struggle to keep up.

• Our delivery speed is outpacing our safety processes.

• Our architectures multiply attack surfaces faster than we can control them.

• We’re expecting human vigilance to solve problems that fundamentally require automation and systemic solutions.

The OWASP Top 10 is still valuable. No doubt about that! But it’s also just one lens.

And in a world where business logic flaws, race conditions, API sprawl, dependency trust, and supply-chain risks can sink a product, organizations need more than a Top 10 checklist.

They need a holistic approach that reflects how software is actually built today.