S2E6: OWASP Top 10 Turns 20: Still Valid, Still Controversial

Transcript

Dan: Hello and welcome to another episode of AppSec Serialized, the podcast about web security and those who practice it. I'm Dan Murphy and with me as always is my cohost Ryan. Hey Ryan, how's it going?

Ryan: It's going great. It's quite chilly these days, but we have a lot to talk about and we've had a great season so far. I know I've learned a lot personally. I've had a lot of fun and I think this is our last episode of the season, so hopefully it's gonna go out with a bang.

Dan: That it is, that it is. And what we're going to be talking about today is a little bit of old, a little bit of new. We're going to be talking about the OWASP Top 10, specifically updated in I think about November of last year for 2025.

Ryan: Yeah, I'm really curious. I've been around OWASP. I grew up understanding it when I went into college. But from your perspective, how did the OWASP Top 10 really originally start? And what was the problem that you saw it was trying to solve at the time?

Dan: It's like an old guy question. So yeah, when it was first introduced, you got to remember that back in the day, 2003 was the first time that this came out. Application security was a different landscape. A lot of us were just hackers who kind of knew how to build secure software cause they knew how to break stuff. And you didn't really have the specialized industry terms build up.

This was in the early days where there was just a lot of information sharing on the internet trying to take that wide world of, hey, if you put something on the web, it's going to get hacked and trying to disseminate the knowledge. So you can almost think in some ways, it was a way to share your notes. It was practitioners helping practitioners just trying to say, Hey, I found this thing. Here's a name for it. Here's a category for it. Here's a way we can actually talk about it on Usenet or whatever back in the day.

The early versions of it were more concrete, I would say, than they are today. We still have some stuff on there that has persisted even after all this time. The number one back in 2003, unvalidated input was the number one thing. Still today, people make the mistake of trusting the end user and on the internet, you can't trust anything that comes to your back end. And there's some other things that we see there, but there's things that have kind of fallen out. Things like SQL injection used to have its own category. It was number four. It was a big deal, XSS in 2003. Buffer overflows.

Ryan: You shouldn't. You shouldn't at all. Don't do that.

Dan: Which is something that you don't hear a lot about anymore. I recall a particular class in which I had to manually smash the stack for fun and profit and get a return to see a vulnerability to be able to show that you can do an overflow. Those are skills that you just don't see with the rise of safer programming languages that aren't doing raw low level manipulations.

And then you also see other more specific stuff like cross-site request forgery or CSRF, which is still around but is less of a focus. So a lot of these more specific things, and the perennial SQL injection as well, they've been kind of rolled into other categories. But originally you can see it's got that origin in the practitioner because they're very specific and it's really kind of a set of shared notes to warn the other guy about what is out there.

And so Ryan, you've seen this change. You started doing security stuff when this was well established. So over the past 20 or maybe not quite 20 years, how have you seen the OWASP Top 10 evolve as you've seen changes in the way that applications are built and in what the attack surfaces are for the web applications and APIs that we've got?

Ryan: I started really in security through high school and college in the mid 2010s. So really in that era of cloud APIs and microservices when those are really starting to take form. But I want to think back. In the early 2000s, when everything started, you had these massive monolithic form-based web apps where injection strings were a big thing because they were all form-based.

And then you had to switch to different frameworks and dynamic apps where you understood that vulnerabilities weren't necessarily disappearing, but they were moving to different layers. And so when we switched to those, when I started to get into it with cloud APIs, microservices, the security issues really became architectural and systemic. Not just coding a bug here, coding a bug there, letting injections happen. It was more the entire architecture of everything working together with clouds and vulnerabilities and how these communicate with those and more best practices.

And then going into the late 2010s, early 2020s, we started to see the influx of DevOps and supply chain. I mean, I think supply chain even now is even getting crazier than it was with what we've seen and talked about last episode with Shai-Hulud and everything with React2Shell. I mean, that started in the early 2020s and apps became that ecosystem. And attackers followed. They were like, great. They're using open source that maybe they're not creating. And now we have one lever for thousands of companies to pull. So that's really where it got really interesting.

And then getting into the 2020s with API, cloud native, zero trust, and now where we are now in the mid 2020s. It's weird to say that mid 2020s now. We have AI going crazy. We have LLMs being put into all of these different components. And behavioral risk. Now security is about intent, influence, misuse, not just around execution.

So it's really interesting to see the development in security and what OWASP has had to do to keep that framework. I'm just happy that it's kept up with it. And I think I have some questions for you maybe a little bit later on around API, LLM stuff and how that's being added and maybe changing. But in terms of the 2025 one that we're looking at now, what stands out most to you in 2025 OWASP Top 10 compared to those previous versions?

Dan: So with that old school one that I talked about, I would say consolidation is probably one of the big things. We've seen a number of specific attacks that have been kind of rolled into these more generic categories. That kind of makes sense when you consider the size and the scale and the number of vulnerabilities that are out there. You kind of do need a broader net to be able to catch everything, so I can get that. There's some movement that makes a ton of sense. Some of it, you kind of scratch your head a little bit at.

So one of the big things: supply chain has moved up – clearly as you alluded to. We have seen an increasing number of software projects that are quilts that are just knit together from all different sorts of open source components. I think that the security of those components is going to continue, as reflected in the priority inside of the OWASP top 10, to be a big deal as time goes on.

And it's funny because in some ways at an organization, if somebody opened up a pull request and they asked the developer, hey, here's 70,000 lines of code. Can we just merge this into the project? There'd be hue and cry and did you do all the static analysis? Did you do this? Did you do that? But if you think about that same pull request being two lines that introduces a third party component that happens to live in a trusted repository? It kind of gets a pass and we've seen cases where that trust has been successfully abused by threat actors. So I think supply chain moving up, it's a good thing. It's a real thing and I'm glad to see that there as well.

A couple things though... Injection moved down by two spots and I might have a small bias here, seeing as we do a lot with injection and I've seen so many things – the stories I can tell.

Ryan: Maybe too much. I know.

Dan: But in all seriousness, I took a look at CISA's KEV, their known exploited vulnerabilities list. And when I saw that injection had kind of come down, I asked myself, I think it's a big vector. And so I filtered them down to the top ones that have been exploited in the last 30 days. And you know what? The number one category there was injection. So it was vulnerabilities, untrusted inputs, getting abused with all sorts of things that would make apps do things that they were never intended to do. So I think injection is a big deal.

Now I understand why it was lowered because it is harder in 2026 to use software frameworks in a way that out of the box are vulnerable. So generally speaking, the software stacks with which we work, they're much more robust. They make it hard. But I actually had an interesting experience. A couple of weeks ago, there was a quick internal app that I had vibed up for an internal demo. You probably saw it Ryan. And I noticed that there was a cross site scripting vulnerability in that. And I was shocked because that's so hard to do nowadays. But it was quick, it was dirty. And with the advent of LLM tools and the ability to go faster than ever, it is possible for some of those things to slip through the cracks. Maybe I'm a little bit bullish on injection in a way that may not be great.

I am happy to see some other new categories though, that talk about the importance of things like monitoring and observability and the lack thereof and how that can get you into trouble and also some of the rolling up of things into the exceptional condition handling. Things that don't happen often are often the things that provide the door through which an attacker can go. So there was actually an ancient Linux kernel integer underflow that I was surprised to still see on the KEV, the top exploited thing, but it's real. Those things are still being exploited and they're definitely around still.

So there's a lot of stuff that has been consolidated in some categories. So overall, I'd say that we see some big categories, but those might feel a little bit obtuse. But when you think about that full security breadth, it does make sense. So Ryan, a question for you, because you get to talk to a lot of our customers at companies, small, medium and enterprise: how are they using the OWASP Top 10? Realistically, what role does that play in a modern security program?

Ryan: From my perspective and what I hear from customers, it's really just an entry point. It's not really an end state. It's often, I would say, the first thing that whether you're a developer, a security professional, CISO roles or things like that, that is shown. It's what AppSec has been. It gives you a good understanding.

I have this vivid memory of my professor who always said the OWASP Top 10 is a compass. It's not a GPS. It's going to point you in the right direction, but it doesn't tell you how to get there or what the traffic looks like. So I think that's really interesting because it really is that framework. There's a lot more there, but it's really a common language that comes across technical and non-technical teams. So when you look at compliance organizations, auditors, they don't have to be technical, but usually they know what OWASP top 10 is. So it really becomes that common language and understanding where that fits between business risk and technical findings.

One main area that I would say it really fits is being a common reference point for audits, onboarding, training. Because I think when I started building a lot of cybersecurity trainings at my last company as a security engineer, I did focus on the OWASP Top 10 and start building trainings for developers on best practices for those to help. But the one thing that I've always said is those baselines, they can become ceilings. We need to make sure that we are careful. We don't only look at the OWASP Top 10, because from what I've seen is a lot of people just scan for OWASP Top 10 and go from there.

Look at the breadth of information that we have, especially here at Invicti, scanning for not just OWASP Top 10, but everything in terms of AppSec: LLMs, APIs, and things like that. So I do think it really is just that compass, which is really going to point you in the right direction and how to do things instead of saying, here's a GPS, here's the final spot, this is where you're going to finish.

Now, Dan, you're running our security research team. How do you think security practitioners view the OWASP Top 10 differently from maybe a CISO or a compliance team?

Dan: Oh yeah, that's a big difference. So I alluded to this a little bit before in that sometimes as a practitioner, the OWASP Top 10 can feel broad. When you're trying to describe to someone whether or not there is an auth issue. Is that an issue where it's a design level issue, which is broken access control, cause you can get in without auth? Is that a security misconfiguration, cause you didn't set up auth in the first place? It can be viewed as something that is not helpful on the day to help a security practitioner get their stuff done.

CISOs do value it because it provides that legal front with that common language to be able to talk. And when they bring something to their executive sponsors, they can say, hey guys, this is a big deal because it is a top three. This is important. We need the resources to fix it. And a compliance team, they can use it as a framework to make sure that they've got coverage for a variety of different things as they're selecting tooling and policies to help that org meet their security requirements.

So it's tricky. Engineers really want that low level depth that helps them get their stuff done. Whereas leaders want clarity. They want to use it as a lens. I actually think that there's a good use case where it can be useful to all. I was taking a look at some numbers and realized that we had 48,244 new CVEs last year. That's a lot.

Ryan: That's a lot. Holy moly.

Dan: Like that's a real lot. It's going up every single year. And those in turn, those CVEs, which are specific exploits of known instances of software, those fall into categories of Common Weakness Enumerations. There's 944 of those CWEs. That's still a lot. That's too much to talk about. Now all of those things go into just 10 OWASP top 10 categories.

10 is a number that humans are very good at. We can remember 10 things. We can very easily count those 10 things. You and I can have a conversation. Having a taxonomy that goes from the huge to the less narrow to the broad, it is useful even for a practitioner to get an idea because that quote that you gave of it being something that can help show you the way, but it's not the actual direction. It's quite applicable. 10 is almost the perfect number for that sort of list unless you come from a vigesimal culture that counts on their hands and feet. But 10 is a good number if you want to have a category.

However, Ryan, I'm gonna ask you a question here. So you do see a lot of organizations. When you give someone a ruler that has 10 distinct tick marks on it, what are some ways that that measure can be misused or misunderstood?

Ryan: So many ways. I think the first biggest one is it's a certification. Oh yeah, we need to get our OWASP Top 10 certification. It's like, that's not what it's there for. It's not a checklist. It's guidance. And there's more to that. It isn't just around OWASP either. There's other ones. You have MITRE ATT&CK, you have NIST 853, and I would say they work with each other.

So you have the OWASP that tells you what commonly goes wrong. You have ASVS that tells you what to build. You have NIST, which tells you how to run your program, which is really awesome, especially when you think about all these government agencies that have been doing these things. They follow those NIST guidelines. And then your MITRE. It tells you how attackers operate. So I love that one. I think you probably do too. Just understanding the mindset of attackers, what they're looking at.

Confusing awareness with actual security outcomes is one thing, but obviously, we scan for much more than just the OWASP Top 10. And OWASP Top 10 is great, but one thing that I've seen in certain customers, in certain organizations, them saying, we only want to scan for the OWASP Top 10. And we do have a policy for that. We can scan for just the OWASP Top 10. But I always recommend to our customers, anyone scanning, is scan for everything. Look for everything under the sun, all of our checks. We have over 3,000 checks and many more. And then you can bucket those vulnerabilities into categories for OWASP Top 10, DISA STIG, NIST 853.

Dan: Mm-hmm.

Ryan: So you're getting the full breadth of security and the knowledge that our security practitioners are putting into a tool and then you're applying those guidelines to see where you fit in them. I really do think using it as evidence of complete coverage in better assessments can be interesting as well.

So obviously the evolution has been happening. It's not just around web apps. And I do think it's interesting that API has the OWASP Top 10 for APIs, OWASP Top 10 for LLM... They've started to branch out. If you're looking at those, they're relatively new. Why couldn't they fit into traditional OWASP Top 10? Why did they have to branch out in OWASP for those different categories?

Dan: Yeah, yeah, they totally could fit. Next question! No, no, but in all seriousness, the reason that you want those is it goes back to that original idea of raising that awareness. So those new categories are sufficiently different that... Maybe to me, putting an LLM attack, where you're ultimately doing some prompt injection or maybe some insecure input validation, where you sweet talk that LLM into doing some XSS instead of injecting a payload that pops up that alert button directly... They're similar, but they're new avenues and the goal of these things is really to raise that awareness.

Much like that original sharing on the internet to make sure that everyone knows what the bad guys are up to, having a specific Top 10 to be able to let people know that the game is changing. To let people know that APIs have, even though some of the vulnerabilities may look similar, it's a new vector and it's a new area that it's kind of hard if you don't have a specific thing that calls out to leadership saying, yeah, what are you doing to secure your APIs? You cannot necessarily see those things. They're out of sight. They're out of mind. Very few CISOs are going to be running curl against their unsecured edge to be able to find things that are hidden, that are just lurking.

So there's value in calling out those new types of vulnerabilities to educate, to make people know that they're there. LLMs, for example, you might think of prompt injection, which is another type of injection, which is in the main top 10, but it is a wonderful conversation to have about how it is different. It is a wonderful conversation to have about how the threats that you thought you might be immune to in the magical new world of AI, they still exist and they're still out there.

So I think that what we'll see over time is that some of those specialized top tens, they'll come, they'll serve their purpose and then they'll get a little bit more genericized. Much in the same way that we have seen things like SSRF – tricking a remote server to making a web request to an address that the attacker controls – that's just part of broken access control as well.

I can see a future like that for some of these more specialized lists, but there is absolutely value in raising the profile of these new attacks in making sure that CISOs have these things. You mentioned misuse before, maybe you're going to have an org that says, excuse me, are your access controls broken? Yes or no. Even if you walk through some of these things and you have that conversation and you really have to assess whether or not the new tools, you're keeping up to date and getting offensive tooling that's going to be able to find these things. It's an important thing to have. So those specialized risks, all joking aside about being able to fit them into a generic one. There is a lot of value in having them because it makes you have that conversation.

Ryan: Yep, absolutely. As I said, when I started getting into security, OWASP was one of the first things that I looked at. It was the guide where I could see all of my websites that I could go try to hack for free, have fun in college and not get in trouble or things like that.

But I want to leave our listeners with a question. And please feel free, if you are listening, reach out to us, throw comments in there. If OWASP was removed, if they removed the top 10 tomorrow, would application security actually get worse? Or do you think the industry potentially maybe has outgrown it or is continuing to look at it? I really am curious, whether you're a CISO, whether you're a security engineer. I fully believe in OWASP Top 10, but I've heard interesting perspectives and we'd love to hear from everyone out there. I think that could be an interesting debate. I think Dan and I probably would debate on it a little bit as well. But I would love to leave it at that. And I've had a really good time this season learning a lot. It's been really fun.

Dan: Excellent. Well, hey, and on that note, this has been another episode of AppSec Serialized. Ryan, thanks so much for being a gracious co-host. It's always fun to hang out and talk security with you. And thanks most of all, to you, our listeners. Have a lovely day, everybody. Bye-bye.

Ryan: Always. Bye bye.

Credits

• Discussion: Dan Murphy & Ryan Bergquist
• Production, music, editing: Zbigniew Banach
• Marketing support and promotion: Alexa Rogers