Every few years, the OWASP Foundation publishes an updated Top 10 list that reshapes how the industry thinks about web application security. The 2025 edition arrived with significant changes that reflect a fundamental shift in where real-world attacks are landing — and where defenses are failing. If your team hasn't reviewed the new list yet, now is the time.
The Evolution of Web Risks
The OWASP Top 10 has served as the industry's de facto benchmark for web application security risks since its first release in 2003. It's referenced in compliance frameworks, audit checklists, training programs, and procurement requirements worldwide. When the list changes, the ripple effect touches every organization that builds or consumes web applications.
What makes the Top 10 valuable isn't just the ranking — it's the methodology. OWASP combines large-scale vulnerability data from hundreds of organizations with a community survey that captures emerging risks not yet visible in historical datasets. The 2025 update analyzed data from over 500,000 applications, making it the most comprehensive edition to date.
But the list is not static, and it shouldn't be. Attack surfaces evolve. Frameworks mature. New architectural patterns introduce new risk categories. The 2025 changes reflect all of these dynamics.
What Changed
The 2025 edition reorganized several categories and introduced shifts that surprised many teams still operating from the 2021 baseline. Here's a breakdown of the key movements:
Injection drops in ranking
For over a decade, injection flaws — SQL injection, command injection, LDAP injection — dominated the top of the list. In 2025, injection has moved further down the rankings. This isn't because injection is "solved" — it's because modern frameworks like Django, Rails, Spring Boot, and Express with ORMs provide parameterized queries by default. The attack surface has narrowed significantly for teams using current tooling. Manual string concatenation into SQL queries is increasingly rare in new code.
Supply chain and software composition risks rise
Vulnerable and outdated components, previously a mid-list concern, has climbed sharply. The expanded category now explicitly addresses software supply chain risks: compromised packages, dependency confusion attacks, and the growing attack surface of transitive dependencies. The Log4Shell incident was a wake-up call, but the 2025 data shows the problem has only grown. The average application now pulls in over 200 direct and transitive dependencies, each a potential vector.
API security gets dedicated attention
With the rise of microservices, SPAs, and mobile backends, APIs have become the primary attack surface for most modern applications. The 2025 list elevates API-specific risks — broken object-level authorization, mass assignment, and unrestricted resource consumption — reflecting the reality that most data breaches now originate at the API layer rather than through traditional web forms.
Cryptographic failures consolidation
What was previously "Sensitive Data Exposure" has been refined into a clearer focus on cryptographic failures. This category now covers weak algorithms still in production (SHA-1 for integrity, RSA-1024, CBC without HMAC), improper certificate validation, and the growing concern around crypto agility — the ability to rotate algorithms quickly as new weaknesses are discovered.
SSRF rises in prominence
Server-Side Request Forgery has steadily climbed the rankings. Cloud-native architectures, with their reliance on metadata endpoints and internal service meshes, have made SSRF a high-impact vulnerability. An SSRF in a cloud environment can lead to credential theft from instance metadata services, internal network scanning, and lateral movement — all from a single forged request.
Here's a practical comparison of how a modern framework's built-in protections differ from manual approaches, illustrating why injection risks have declined:
# Manual approach — vulnerable to SQL injection
def get_user(request):
email = request.GET['email']
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")
# Modern framework — ORM handles parameterization automatically
def get_user(request):
email = request.GET['email']
user = User.objects.filter(email=email).first()
# Django's ORM generates parameterized SQL — no injection possibleWhen developers use the framework's ORM instead of raw queries, entire classes of injection vulnerabilities disappear without the developer needing to think about escaping or parameterization. This is defense by default, and it's why injection has dropped in the rankings — not because it's less dangerous, but because modern tools have made it less prevalent.
Why These Changes Matter
The ranking shifts aren't academic. They reflect where real breaches are happening. When supply chain attacks move up the list, it's because organizations are being compromised through their dependencies at an increasing rate. When SSRF gains prominence, it's because cloud environments have made the impact of SSRF exponentially worse than it was in traditional data center architectures.
"The OWASP Top 10 doesn't tell you what's theoretically dangerous — it tells you what's actually being exploited. When the list changes, your threat model should change with it."
Organizations that anchor their security programs to the Top 10 need to recognize that the list is a living document. Using the 2021 priorities to guide 2026 security investments means misallocating resources. You might be spending 40% of your training budget on injection prevention while your actual risk surface has shifted toward API authorization flaws and dependency vulnerabilities.
What This Means for Your Team
Understanding the changes is step one. Acting on them is what separates mature security programs from checkbox compliance. Here are four concrete actions every development team should take:
- Update your threat models — If your threat model still lists SQL injection as the top risk for a modern SPA backed by an ORM, it's outdated. Re-evaluate based on your actual architecture. API authorization, supply chain integrity, and SSRF may deserve higher priority.
- Adjust training priorities — Developers need to understand the risks that are actually relevant to their stack. A team building microservices needs deep training on API security and SSRF, not another session on XSS in server-rendered HTML they don't write.
- Review dependency management practices — Do you have automated dependency scanning? Are you monitoring for known vulnerabilities in transitive dependencies? Do you have a process for responding to a compromised package within hours, not weeks?
- Don't ignore the "old" risks — A lower ranking doesn't mean a lower impact. Injection is still devastating when it occurs — it's just less common. Teams using legacy systems, raw SQL, or custom query builders should still prioritize injection prevention. Context matters more than ranking position.
Beyond the Top 10
The OWASP Top 10 for web applications gets the most attention, but OWASP maintains several specialized lists that deserve equal consideration. The API Security Top 10 addresses the unique risks of API-first architectures — broken authentication, excessive data exposure, and lack of rate limiting. The Mobile Top 10 covers insecure data storage, insufficient transport security, and client-side injection risks specific to mobile platforms.
For teams building rich client applications, the Client-Side Top 10 addresses DOM-based vulnerabilities, insecure client-side storage, and third-party script risks that traditional server-focused lists miss entirely. Comprehensive security coverage requires looking at all the lists relevant to your architecture, not just the flagship Top 10.
The 2025 OWASP update is a signal, not a checklist. It tells you where the industry's risk center of gravity has shifted. Use it to recalibrate your priorities, update your training, and have honest conversations about whether your security program is addressing the threats that actually matter today — not the ones that mattered five years ago.