The OWASP Top 10 for 2025 is the latest standard awareness document for developers and web application security, representing a broad consensus about the most critical security risks to web applications.
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about the OWASP Top 10, or Top 13, as it may be. And my guest for that is a returning customer, Tanya Janca. Hello.
Tanya Janca: Hi, Ryan. Thank you so much for having me back.
RD: It’s always a pleasure. So last we talked, you were doing your security work, but now you are part of the OWASP team. Can you tell us a little bit about how that came about?
TJ: Yeah, absolutely. So I’ve run a chapter before. I’ve run a project before. And basically, OWASP was like, what are you going to do next for us? Because of course, I’m going to do something. And there was a bunch of different projects that I met with to talk about joining which one. And then I don’t know if you know Star Brown, but she is head of projects at OWASP. So she’s a staff member, and she’s pretty great. And she said the top 10 team kind of needs to be dragged across the finish line. And you are like a person that gets things done. And, you know, you love OWASP. They love OWASP. Like, what if I made an intro? So I met with Andrew Vanderstock, who’s the executive director, but also is on the top 10 team. And he’s like, Tanya, all of us have 400 things going on. And we’re a bunch of wild cats and we need some herding. Do you feel like herding cats? I’m like, AppSec cats? That sounds great! And so we met and we had one meeting and basically, I took notes. These are your action items. This is what we’re doing. I’ll see you next week. And then the next week, Neil’s like, can we just tell you how much we love you? Why did you not join our group like 10 years ago? I’m like, I don’t know. I guess I was doing some other silly project. We get along so great.
RD: Silly projects like the Canadian election security, right?
TJ: Yeah. Yeah. Silly projects like that. Like trying to make the first secure coding law in Canada that I’m currently working on.
RD: The OWASP, in general, when I found it, it’s an amazing resource for what is considered the vulnerabilities du jour, right? Every year you have the top 10. This year, what’s different? What’s shifted for the top 10?
TJ: So we actually only do the OWASP top 10 every three years, which sucks. It’s because it’s so hard to get data. So data aside, what changed? Two big things changed essentially. So one, we got to take some stuff off the list, which was great. So cross-site scripting used to be its own item on the list, server-side request forgery, cross-site request forgery. Various individual vulnerabilities used to be on the list. And we did such a good job of promoting that it was an issue that the industry responded and it fell off the list, which brings me great joy. But the two really big changes are we changed using outdated and vulnerable components to the entire software supply chain. So your IDE, your CI, your code repository, every single thing that you use to maintain or create a piece of software, all of that is part of your supply chain. And if it’s being attacked, we’re in trouble. So I was like, listen, I know we don’t have the data to fully support this. So let’s ask the community what they think. And across the board, 100% of them are like, this needs to be on the list. So we’re like, we are correct. If hundreds and hundreds of community members agree, then it’s probably good. And then the other one is mishandling of exceptional conditions. So originally when we looked at it, poor code quality was on the list, and I was like, no, poor code quality — that’s all of them. That’s everything. And I was like, let’s be quite blunt. What is the remediation of poor code quality? What if you tried sucking less? Have you tried not sucking? That’s completely unconstructive and totally unhelpful. So I was like, that is an unacceptable bucket. Now we’re going to break things down further. What do we see? And so we had lack of application resilience — so your app does not know how to get back up or stay up — versus mishandling of exceptional conditions, which means your error handling is not right. So something’s happening and you are just doing a poor job of reacting and responding and/or preventing it in the first place. And they tied. Like the numbers were almost exactly — I think it was off by two or something. It was so close. Like when you have millions and millions of results. And I was like, listen, if we resolve mishandling of exceptional conditions, we solve almost all of application resiliency. But if we just do application resiliency, it does nothing for mishandling of exceptional conditions. And we’re only allowed to put 10 things on the top 10. I want to fight for the one that is going to solve two issues. And they’re like, you know what? That’s a pretty reasonable answer. And then we started writing. Brian did most of the data work, I did a lot of the writing, and Neil handled the website, releasing, and publishing. You all sort of divide things by strength, right?
RD: Yeah, yeah. There’s a bunch of stuff I want to get to. So you talked about the difficulty of getting data and the data that you gather. What is the data and how do you gather it?
TJ: This is the best question ever. So for everyone listening, next time, I want your data. Basically, what people are willing to share with us is generally a whole bunch of pen tester boutique shops that will share their anonymized reports with us. And then we have a whole bunch of vendors that make static analysis or dynamic analysis tools, and they’ll share their data with us. What we do is we look at CWEs — common weakness enumerators — which is like a pattern. Injection is a pattern that is covered by that, versus CVEs — common vulnerability enumerators — which is a specific individual vulnerability in a product. So if you are running Windows Server 2018 R2 Service Pack, and so am I, we have the same exact vulnerability. So we want to look at patterns because we’re looking at custom software, and each piece of custom software is a beautiful snowflake.
The data that I really, really want is postmortem reports, because then we could have the supply chain information. Then we could have the vibe coding and all the other types of things showing how this actually happened. Because injection is still a problem — it’s still on the top 10 because it still sucks very badly. But how did that injection happen? Did a software developer write that code? Did an AI assistant write that code? Did they copy it from our favorite forum in the entire world? Where did they get this? Is the injection actually part of a third-party dependency that they installed, and maybe that dependency was intentionally malicious? How did that injection actually happen? Because not a lot of developers are doing SQL injection anymore — pretty much all of them know better. So the data that we got versus the data that we desire to have is quite different. Next time we do a data call, I’m going to do some begging. We’ll see how it goes. Because Brian got most of the data; I only brought in around 2 million records — two or three vendors at the last minute. But I only joined the project in July, we had our first meeting in September, and we released in December. That’s pretty fast for a three-year iteration. But could you imagine asking an organization, hey, can we have all your postmortem reports from your security incidents? They’re like, no, you may not.
RD: Sure. And I know that for certain breaches, companies have to disclose it. And a lot of people do just postmortem reports anyway. Are those helpful?
TJ: Yes and no. So I was at a conference called Snowfrog last week in Denver, and I gave this talk. Partway through, I was like, okay, so it’s an AppSec conference, so almost everyone works in application security. I was like, who here is having software security incidents? And maybe a third of them put up their hand. And I was like, okay, so for the rest of you that are having incidents and don’t know, let’s talk about that. Because if you have software on the internet, I assure you, you are being attacked. And a lot of people just don’t even know what to look for. They’re not even aware that it’s occurring. And so here I am asking not only that you are able to notice, but that you are capable of responding and that you actually have the time and the energy to do a postmortem and write that report up for me and then share it in an anonymized version. Like when I help people with their AppSec programs through consulting, I’ll work with them and say, let’s get some metrics on the incidents you’ve had. And most of them don’t have anything like that. They don’t know that we’ve had this many incidents, and this percentage was AppSec, and that’s how much it cost us, and this is how many hours it took us, and this is why it’s worth investing in our program. Most of them just have their hair on fire.
RD: The preemptive security stuff is still a little distant, isn’t it?
TJ: Because what I care about, Ryan, is not what a static scanner finds. What I care about is what is getting in — what is being attacked more often and what is working with these attacks. Unfortunately, we’re not really getting a lot of data on that. Like when we look at, for instance, the Verizon breach report or the annual breach report from CrowdStrike, and reports from Mandiant and others doing really cool work in that space — even the way that they’re reporting it, in my brain it maps differently. The past two or three years, there’s been a lot of focus on identity-based attacks and credential compromise, which is critically important, but it can obscure what’s happening at the application layer. Getting better postmortem data on application-level incidents is still one of the biggest gaps the OWASP Top 10 team is working to close.
