Anvaya’s Thoughts on the OWASP Top 10 (2025): What the New List Says About the Next Breach

The latest OWASP Top 10 is out, and there are no surprises. For a firm that’s used OWASP as a practical testing guide for nearly two decades, this update confirms what we see in real environments: modern apps are more complex than ever, the supply chain is bigger than ever, and the gap between “we shipped securely” and “we’re actually secure” is still where incidents are born.

OWASP continues to deliver one of the most valuable security resources on the planet: free, usable guidance for developers, security teams, and leadership. And this 2025 Top 10 shines a bright light on the failures that quietly stack up.

Below, we’ll walk through each category with what it looks like in the field, why it keeps happening, and what teams running real programs can do about it.

1) Broken Access Control

If there’s one category we expect to find in almost every application we test, it’s Broken Access Control. And it’s not because teams don’t care, it’s because access control is deceptively hard to implement consistently across a growing application.

We routinely see privilege escalation, IDOR (Insecure Direct Object References), horizontal access issues, role creep, and permission drift.

A common pattern: companies focus heavily on keeping people out of the application, but once a user has an account, the internal boundary lines get blurry. A single endpoint without proper authorization can quietly undermine everything else.

2) Security Misconfiguration

Security Misconfiguration rising from #5 to #2 feels honest. As organizations adopt more frameworks, plugins, managed services, and turnkey infrastructure, misconfigurations multiply quietly, spreading across layers.

We see misconfiguration everywhere. One of the most painful examples we still see: storage exposure combined with long-lived secrets (the “forever token” problem). A bucket object meant for internal use gets shared, cached, indexed, or leaked, and now a token or signed URL becomes a standing invitation.

Why it’s scary: Misconfiguration is rarely “one thing.” It’s usually a chain: permissive network + verbose errors + default credentials + exposed management endpoints. That’s how small mistakes become large incidents.

3) Software Supply Chain Failures

This new category replaces “Vulnerable and Outdated Components,” but the new framing is more accurate: modern apps are ecosystems. Your code is only part of what you ship.

Yes, we still find the classics like old dependencies that never get updated, build pipelines that trust unsigned artifacts, libraries pulled from public registries without integrity verification.

But the scarier version is supply chain compromise upstream of your repo, such as a developer tool or plugin introducing risky code patterns, dependency confusion, typosquatting, or malicious packages landing in builds, CI/CD credentials get abused to alter release artifacts.

4) Cryptographic Failures

“Cryptographic Failures” is a technical label, but most leaders understand it as: sensitive data ends up where it shouldn’t.

This includes classic problems, weak or missing encryption for data at rest or in transit, poor key management (keys stored like passwords), secrets showing up in logs, URLs, headers, referrers, or analytics tools.

This means attackers don’t need to break encryption if they can just find the data lying around in the open, or recover it from logs and telemetry.

5) Injection

Injection dropping to #5 feels right in a world with stronger ORMs, safer frameworks, and better defaults, but injection is far from gone.

We see fewer obvious “low hanging fruit” payloads, but more, edge-case SQLi and stored/staged XSS through complex rendering paths.

Something to watch with injection is AI. AI tools catch a lot of injection patterns quickly (which is great). But AI-generated code can also introduce subtle injection risk when it “helpfully” concatenates strings or bypasses validation to make things “work”.

6) Insecure Design

Insecure Design sliding down makes sense: many teams are adopting secure design earlier, and mature SDLC programs catch obvious design mistakes sooner.

But design flaws aren’t going away, and when they show up, they’re often systemic. This tends to happen when newer parts of the applications are rushed leading to missing threat modeling for a new feature or business logic that can be abused even when the code is “secure”.

7) Authentication Failures

Authentication remains a minefield of nuance: flows, throttling, session handling, MFA UX tradeoffs, SSO configuration, edge cases, and integrations.

We still commonly see account enumeration (different error messages, timing differences, or response behavior), weak password policies, session issues like long-lived sessions, missing invalidation, poor token handling, and MFA bypass paths in account recovery and special flows.

8) Software or Data Integrity Failures

This category is all about trust collapsing in your code, your builds, your updates, your pipelines, and the data your system uses to make decisions. It’s what happens when attackers don’t try to “hack the app” directly… they hack the things the app believes.

In the real world, integrity failures show up when software updates are delivered without strong verification, CI/CD pipelines are too permissive or poorly isolated, release artifacts can be swapped, overwritten, or rebuilt without accountability, services accept “trusted” inputs from other services without validating authenticity.

If Broken Access Control is “you can do what you shouldn’t,” then Integrity Failures are “the system did what it shouldn’t… because it was given something it shouldn’t have trusted.”

9) Logging & Alerting Failures

If you’ve ever been in an incident response situation, you know the nightmare: you can’t answer basic questions quickly.

What happened?

Who did it?

How long has it been going on?

What data was accessed?

Are we still compromised?

Logging and alerting failures aren’t flashy, but they’re foundational and they’re still missed because many test plans don’t treat them as “security requirements.”

When you don’t log the right things (and alert on them), attacks do worse than succeed. They succeed silently and who knows when they will be discovered.

10) Mishandling of Exceptional Conditions

This new category validates what we see constantly: even sophisticated applications struggle under abnormal conditions. Edge cases are where secure systems unexpectedly “fail open.”

Examples include, error handling that leaks stack traces, tokens, internal endpoints, or configuration, race conditions that bypass checks, timeouts and fallback paths that skip key validations, and overly verbose error responses that become reconnaissance gold.

Exceptions are the cracks in the wall. Attackers don’t attack your happy path—they attack the path you didn’t think anyone would hit. Security needs to be considered from every angle or you are just preventing one way into your application while leaving a hidden door open.

Closing Thought: The list is a warning system, if you treat it like one

The OWASP Top 10 are not the only risks that show up in application security, but these are the risks most likely to show up in real systems. If you’re accountable for application security, the goal isn’t to memorize the list, it’s to build programs that prevent these failures repeatedly, across teams, consistently. Anvaya can help with finding these risks before attackers and give you guidance for your application security as a whole. Feel free to contact us for more information.