The 2025 OWASP Top 10 is here, and it might be my gray hair speaking, but it seems everything old is new again. For old hats–like myself, who relied on the initial 2003 list to guide my early penetration testing career (thank you, Classic ASP, for the good times)–the 2025 list has less shocking revelations and more a sobering confirmation: there is a lifecycle of web application security, and it is cyclical. This does not at all dismiss the value of the Top 10 project; it takes herculean amounts of effort to gather and analyze data from multiple consultancies, tool vendors, and security teams. The project acts as a means to shine a light on where web application security should be focusing its efforts, and a shock in the Top 10 list would mean the industry has missed the boat and has not been paying attention. The few surprises on the list this year, though, draws on concepts that have been discussed in security research since the 1970s (Really, just go read the Ware Report if you never have.)
As someone who’s been around the block a few times, you start to notice the pattern where attention shifts as defenders fix popular flaws, pushing attackers to focus on less-traveled, yet familiar, vulnerabilities.
I decided to dive into each of the updated risks (with callouts for various vulnerabilities I see on a basis) with my feelings as someone who has been around since the inception of the Top 10 (anyone else remember Remote Administration Flaws?) and summarize some thoughts on each of the identified risks.
A01:2025 – Broken Access Control
My friend (and co-worker) Justin Larson likes to say that Insecure Direct Object References (IDOR) pays our salaries. He’s not wrong, given the amount of authorization issues we see regularly during assessments. I have a hard time seeing this risk changing in the future, either. While IDOR or simple authorization issues may reduce in number, this category is at its core business logic flaws. Some of the first flaws I found as a clean-shaven, wide-eyed, fresh security consultant involved changing ID integers on portals for customer energy bills to see another user’s energy usage. While nowadays I may need to discover some UUID to perform the same action, the risk and lack of security around these calls just hasn’t changed that much.
A02:2025 – Security Misconfiguration
I will trust the team on the numbering with this one, as configuration issues continue to introduce additional risk to most applications. My view into these issues is very dependent on the scope of our current task and what technology supports an application. Web server, cloud, framework configuration flaws account for quite a few issues and often fall outside of a developer’s purview. These lines get crossed and all the sudden cloud storage with customer records is exposed to the world at large. Or maybe a software update resets administrative credentials back to the default (ask me over drinks how I know).
A03:2025 – Software Supply Chain Failures
This category is new(ish) for the 2025 list, and could be categorized as a bit of a surprise. Combining Vulnerable and Outdated Components from 2021 with the risks from attackers performing watering hole attacks targeting high-value package repositories and maintainers. Sometimes we need a bit of a shock to the system in these lists, but we should have seen it coming with the great research and breaches happening in this space. If I were building the list, this may even rank higher than configuration flaws. Even a cursory glance at security news (e.g. Shai Hulud, Indonesianfoods) shows the prevalence and increased scrutiny on this space.
A04:2025 – Cryptographic Failures
Agree or not, the name of this risk still gives me pause, even though I understand the need to include additional CWEs in with Sensitive Data Disclosure. What I don’t like is that the term “Cryptographic” spurs thoughts of encryption keys, token generation, cryptographic algorithms, and NFTs. I end up arguing with engineers and developers about transport layer encryption, when we should really be talking about data protection.
A05:2025 – Injection
2007 called and wants its Injection Flaws back. At least it now pulls together all of the previous “injection” flaws that were their own category. Command Injection, Cross-Site Scripting, Unvalidated Parameters, and SQL Injection have all featured on their own in the past. Risk of each flaw has reduced with industry maturity, frameworks, and developer experience, so a combined category makes sense.
A06:2025 – Insecure Design
Oh good, a catch-all risk for all of the others and anything else we have seen over the last 25 years. No matter how you look at it, the whole list has commonalities between CWEs and risks. Any AppSec engineer can talk a specific vulnerability into two or three categories depending on where in the SDLC the flaw is introduced. On the positive side, inclusion of this risk in the Top 10 has highlighted the need for Threat Modeling, Security Requirements, and other tasks that have been highlighted as “Shifting Left”.
A07:2025 – Authentication Failures
Okay, so now I want to argue, or at least mildly disagree with a ranking. I see authentication failures in a high percentage of assessments and feel like the industry puts little weight into these risks. Taken by themselves, authentication vulnerabilities may only be low or medium severity, but I have seen them combined to great effect to compromise accounts, expose data, and access administrative functionality. And yes, I still consider email address/username to be a piece of the authentication puzzle. Enumeration is an often overlooked and under-rated vulnerability.
A08:2025 – Software or Data Integrity Failures
The introduction of this flaw in the 2021 list was a yawn for me, maybe because the initial read was related more to software integrity checks during install. I am coming around to agreement that it needs to be included at some level, given the dependence of most software on third-party services and components. Research into subdomain takeovers and dangling domains show how crucial these integrity failures can be.
A09:2025 – Logging & Alerting Failures
Ah! Vindication! The Crocs & Socks is still here. I get the ranking. It seems that most of the industry, author excepted, ignores logging failures until the breach happens. I was guilty of this during my initial introduction to security, but had a quick lesson in application logs, forensics, and gaps in coverage trying to identify successful SQL injection attacks in the early 2000s. Logs and alerts matter. Third party interactions and integrations can introduce gaps most developers won’t think about during development.
A10:2025 – Mishandling of Exceptional Conditions
Finally, the second new risk category for 2025. Anytime an application or infrastructure fails in an insecure manner, a bug bounty researcher writes his first AI-generated submission. Okay, maybe not. Denial of service, failing open, extra parameters, and just generally unexpected behaviours are all accounted for.
Omissions
So what are we missing? The inclusion of Server-Side Request Forgery into Broken Access Control (aka Broken Authorization) means there are no single-vulnerability risks in the Top 10 for the first time. Categories have replaced vulnerabilities, with the majority of the risks even labeled as a collection of failures or conditions. I am not sure if this means we have matured as an industry or if we are missing an opportunity to highlight new and upcoming research. The list has morphed from the original “Top 10 Web Application Vulnerabilities” to “Risks” as practitioners and developers have become increasingly aware of the dangers operating on public networks. While specific vulnerabilities have been “fixed”, developers must still be trained on the dangers of string concatenation, input handling, and output encoding.
Consider the AI of it all
While it is too early to include AI in the list, it doesn’t take a prophet to see that it is going to change the risks of operating an application on the web. Whether that means that vibe coding applications include old vulnerabilities (yes, we have indeed seen a resurgence of SQL injection flaws in the last 12 months) or AI agents find and fix flaws before they make it into production, the AI effect should be reflected in the list in some manner. While it was premature to add an AI-specific risk this time around, it’s going to happen in the next iteration, if not before.
What the Top 10 gets right
The OWASP Top 10 is an awareness document meant as a guide for application security programs. For years, I have harped on the early security triad of AAA (Authentication, Authorization, Accounting) as the baseline we should be using for application security programs. The representation of this triad in the list is confirmation that the security research conducted against computer systems in the 70s and 80s was correct. CIA (Confidentiality, Integrity, Availability) is also well represented. After seeing OWASP struggle to find its voice through the Top 10, this inclusion is exactly where it should be.
What’s Next
From someone who has been around the block a few times with these OWASP updates, realize that the OWASP Top 10 project is now (finally) mature and any expectation that it will change more than 10-20% between iterations is unrealistic. It is not surprising anymore that my favorite talking points, errr, specific risks are not reflected directly in the list. Industry-wide lists are helpful for new applications and training developers, but will not address every application, language, framework, or organization. The proliferation of the other OWASP Top 10 lists is a testimony to the desire to apply the same sort of thinking to other technologies and development techniques.
So take this list and use it. Develop your own Top 2, 4, 5, 8 or 10. Identify the risks that speak to you and your organization and improve your posture with this new focus. Integrate the categories into training, show examples, look for these flaws in that newly-vibe-coded application. In short, apply the principles and let’s make the web less risky. For everyone.
Seth