The King is Dead: Why OWASP 2025 Changes Everything

The 2025 update to the OWASP Top 10 marks a real paradigm shift, showing how the world changed over the past couple of years.t

And while code flaws are still a major hitpoint on the list, the 2025 update proves that architecture and supply chains have risen in importance even further than we thought.

With the explosion of "Vibe Coding" (AI-generated code that works on the first try but fails on the second) and ephemeral cloud infrastructure, our attack surface has fundamentally mutated.

Secure Coding won't get you very far it the same care is not applied to the underlying infrastructure, architecture, pipelines, used compontents, ...

Let's do a breakdown of the new world order, and why your next audit might look.. a little different.

The Big Shuffle: 2021 vs. 2025

A01:2025 - Broken Access Control

#1 stays at the top.

The top issues remain on the throne. IDORs, broken ACLs, and privilege escalations are not going away.

If anything, AI-assisted development is making this worse. AI is great at writing the "Happy Path" (functionality) but terrible at understanding the "Negative Path" (authorization boundaries).

Note: SSRF (Server-Side Request Forgery) has been merged into this category. It is no longer a standalone bug; it is an authorization failure where the server is granted access it shouldn't have.

A02:2025 - Security Misconfiguration

The new runner-up.

This rocketed from #5 to #2, and it tells you everything you need to know about modern dev, where deployed YAML files are a bigger issue than a server missing a patch.

• The Offenders: Unnecessary features enabled, default accounts (still!), and the classic "cloud sprawl": buckets, lambdas, and containers left wide open because someone forgot a false flag in Terraform.

A03:2025 - Software Supply Chain Failures

The New Heavyweight.

Remember "Vulnerable and Outdated Components"? This is its bigger, meaner evolution, not just "using an old version of jQuery". This is about the integrity of the entire ecosystem.

• The Reality: Do you know where your Docker container actually came from? Did your developer just npm install a typo-squatted package because an AI hallucinated the name? If you don't have an SBOM (Software Bill of Materials), you are flying blind.

A04:2025 - Cryptographic Failures

Still dangerous, but slipping down the list. Why?
Because frameworks are getting better at doing the heavy lifting for us.

• The Risk: The issue is rarely "we wrote our own crypto" anymore. It's now "we leaked the private key in a public repo" or "we are using a weak Diffie-Hellman group in our TLS config."

A05:2025 - Injection

Once the undisputed champion of vulnerabilities, Injection has fallen to #5.

• Why: Modern ORMs and prepared statements have, in parts, killed classic SQLi (yet you still find it in real engagements! Keep looking!)
• The Twist: Don't get comfortable. While SQLi is dying, Command Injection and Prompt Injection (in LLMs) are filling the void. The mechanism is the same: untrusted input hijacking the control flow.

Separate your logic flow from your data flow! They should never interfere with one another!

A06:2025 - Insecure Design

This category captures the "Shift Left" failures. You can't patch a flaw that was baked into the architecture on the whiteboard.

• Examples: Storing passwords in plain text (or weak ciphers), trusting client-side validation, or failing to rate-limit expensive APIs (leading to Wallet Denial of Service).

A07:2025 - Authentication Failures

We are getting better at passwords (MFA is helping), but we are getting worse at session management.

• The Trend: Instead of guessing passwords, attackers are stealing session tokens (e.g., Pass-the-Cookie attacks). If your session timeouts are too long or your token rotation is weak, MFA won't save you.

A08:2025 - Software or Data Integrity Failures

Distinct from Supply Chain (A03), this focuses on internal integrity.

• The Scenario: An attacker injects code into your CI/CD pipeline, modifying the application after the code review but before deployment. If you aren't signing your artifacts, you have no way to prove what is running in production is what you approved in Git.

A09:2025 - Logging & Alerting Failures

The "Silent Killer."

• The Problem: Most companies log too much noise and not enough signal. If an attacker brute-forces your login for 4 hours and no alert goes off, you failed this category.

AI analysis of logs is on the rise because of this, yet.. if it will really solve the issue, time'll tell.

A10:2025 - Mishandling of Exceptional Conditions

The Newcomer.

This is the most interesting addition to the list. It replaces the old SSRF spot.

• The Logic: What happens when your system fails? Does it fail securely (closed)? or does it crash, dump a stack trace with environment variables to the user, and leave the connection open?
• The Driver: In the age of microservices, "errors" are constant. Mishandling them, by ignoring them or failing open, is a massive vulnerability class.

Analyzing the Trends

Supply Chain is the new RCE

The Driver: The xz-utils backdoor and the SolarWinds aftermath.

In 2021, we worried about outdated libraries. In 2025, we worry about malicious ones. With modern stacks pulling thousands of transient dependencies, npm install can effectively be "RCE-as-a-Service."

The integrity of your build pipeline is now as, if not more critical than the quality of your code.

Misconfiguration is the new SQLi (in terms of importance)

The Driver: Infrastructure as Code (IaC) and Kubernetes.

Complexity is the enemy of security.

A single misconfigured S3 bucket policy or an overly permissive K8s ServiceAccount allows lateral movement faster than any injection attack. The rise of A02 reflects that we have made infrastructure so complex that humans struggle way more often to configure it securely without automation.

The "Fail Open" Problem (A10)

The Driver: AI Agents and Microservices.

This new category addresses resilience. When an AI agent hits an edge case it wasn't trained on, does it hallucinate credentials? When an API times out, does it default to "allow"? This is about Resilience Engineering. We moved from monolithic apps that either worked or didn't, to distributed systems that can exist in a constant state of partial failure.

Actionable Advice: Update Your Stack

For Breakers

• Hunt the Pipeline: Can you inject code into the build artifact? Can you compromise the private registry?
• Fuzz the Edges (A10): Test "Mishandling of Exceptional Conditions" by forcing timeouts, sending malformed JSON, and triggering race conditions. See if the system "fails open" into an undefined state.

For Builders

• SBOM is not optional: You need a Software Bill of Materials. If you don't know what is running, you can't patch it.
• Hardening over Code Fixes: The rise of A02 proves that a hardened environment (Linux/macOS hardening, restrictive container policies) is often high-ROI than chasing every minor code bug.
• Self-Plug: This is exactly why I’m building my Go-based Hardening Tool. It automates the checks for A02 and A10 that manual audits miss.

Conclusion

The OWASP Top 10 2025 is a wake-up call to stop treating security as a code problem and start treating it as an engineering problem.

I’m currently updating my personal checklists to reflect these changes. Want the raw Markdown checklist I use for my client engagements?

See you next time around!