Looking at the OWASP Top 10 2025 Release Candidate recently made me feel… old. Not the “I’m getting grey beard hair” kind of old, more like the “I remember when this list first came out” kind of old. Okay, maybe a little with the grey hair.
To paint the picture for those who may not recall 2004: We had just landed the rovers on Mars, Usher & Maroon 5 were a permanent fixture on the US charts, the dot-com bubble hangover was lifting, the memory of 9-11 was fresh in people’s minds, and we had the global conflicts to show for it.
In cybersecurity, we were witnessing a shift. That January, the MyDoom mass emailer worm caused approximately $38 billion in damage globally, and variants would be seen in the wild for nearly five years. Symantec reported a 366% increase in phishing and predicted that it would continue to rise. They were right. Significantly, they also noted that over 40% of the vulnerabilities documented between July 1 and December 31, 2004, were web application vulnerabilities, representing a 39% increase over the previous six months. This was a disturbing trend, given that we were betting the farm.
This was the backdrop when OWASP released its Top 10 Web Application Security Risks, version 2. It was a snapshot of the most critical vulnerabilities we faced at the time.
What’s changed since then?
Fast forward to today, and the trends in cybersecurity sound very different yet feel vaguely familiar:
- The concept of phishing - fooling people into clicking on a malicious link via email - has expanded to target the supply chain and other vectors: smishing, vishing, domain squatting, poison packages on npm, malicious browser in browser fakery etc. It’s gone from spray and pray to poison the well.
- AI-powered social engineering augments the efforts of those executing the above attacks. It’s now possible to fake a voice or even a video feed.
- Desktop viruses of old have given way to cloud misconfigurations
- Those script kids of 2004 have levelled up and become ransomware-as-a-service operators, further lowering the barrier to entry for new miscreants to play dirty
And finally, web apps have only increased their importance, with APIs and microservices, alongside OAuth and OIDC encouraging machine integration over the internet.
OWASPs Top Ten over time
For the uninitiated, this awesome community effort strives to collate quality data about the nature of web application cybersecurity attacks and publish them to web developers worldwide for free. I recommend being aware of its contents at all times if you’re in the business of web application development in any capacity.
When we compare how the OWASP Top Ten has evolved, it provides us with an interesting window into not only how attacks have evolved, but also how we’ve responded.
There’s an “I” and “A” in “CIA”? Who knew?
For decades, developers treated availability and, arguably, integrity as “operations problems” - write the code, throw it over the fence, let ops deal with uptime and log repudiation. That DevOps-shaped hole in our security posture is exactly what we’re still trying to fill with CI/CD.
Something shifted around 2017. OWASP added “Insufficient Logging & Monitoring” to the Top 10, essentially telling developers that ‘your job doesn’t end when the code compiles’. Good logs are a love letter to your support teams and incident responders. You must design observability as a feature, not an afterthought.
By 2021, this evolved further with “Software and Data Integrity Failures” entering at #8. Now we’re not just asking, “Can you detect when you’re breached?” but “Can you prove your build pipeline hasn’t been compromised?”
An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise.
OWASP Top 10 2021, A08: Software and Data Integrity Failures
In 2025, we’re being much more prescriptive: use integrity checks for artifacts, please!
An insecure CI/CD pipeline without consuming and providing software integrity checks can introduce the potential for unauthorized access, insecure or malicious code, or system compromise.
OWASP Top 10 2025RC1, A08: Software and Data Integrity Failures
Translation: Supply chain security isn’t optional anymore. If you can’t verify what went into your build, you can’t trust what came out of it.
The pattern: We spent 20 years perfecting Confidentiality (encryption, access control). We’re finally realizing that data you can’t trust or systems you can’t observe are just as dangerous as data you can’t protect.
Buffer overflows have operating system-level mitigations now
Buffer overflows (also known as BOFs), once the bane of C/C++ programmers, were a significant issue, primarily due to the prevalence of Apache and IIS web servers in the wild. This type of attack would be a critical remote code execution issue. Many inexperienced web server administrators would also run Apache or IIS with a high level of privilege out of laziness and a lack of awareness.
Today, not only are more webservers likely to run managed code (i.e., safe from buffer overflows by design), operating systems have stack protections that can randomize memory layout (ASLR), dynamic execution prevention and the like, making those BOFs much header to take advantage of should they exist.
Supply chain attacks emerged
We built websites differently in 2004, too. The concept of npm install leftpad didn’t exist. Sharing code happened via blogs and dedicated code-sharing sites, which in theory could have been a vector, but the reality is that they weren’t used in the same capacity as a package would be leveraged in 2025.
Today, there are over 400k npm packages alone. This makes for a juicy target. In 2019 we all learned that a mere 20 compromised package maintainers on NPM could potentially infect over 50% of the entire ecosystem practically overnight, making for a very juicy target.
This trend continues with the discovery of developer-targeting malware like glassworm via marketplaces for our text editors, of all things. Notably, glassworm channels the bad old days of MyDoom’s wormable nature.
AI, obviously
You might be surprised that there is nothing related to AI or LLM’s in the OWASP Top 10. Well, good news!
Because it’s such a unique space, the OWASP organization has given it a Top Ten all its own, and you will note that its number one issue is… You guessed it… Prompt injection!
The uncomfortable constants
What’s stayed the same? In 2004, 70% of vulnerabilities were classified as easily exploitable, and 97% were considered moderately or highly severe by prwire.
In 2025? The numbers are actually worse. Roughly 38% of reported vulnerabilities in 2025 are rated High or Critical severity (CVSS ≥7), Early 2025 actually saw a spike in Critical CVSS 9+ vulnerabilities compared to prior years.
In 2024, 42% of analyzed vulnerabilities had publicly available proof-of-concept exploits, significantly reducing the technical barrier for cyber-criminals.
At least by this yardstick, in 20 years we have little to show for our attempts at securing technology. We’ve definitely improved at distributing the same problems across more complex infrastructure, though.
Access controls - still broken
Broken access control is #1 on the OWASP Top 10 for a reason. As an industry, the economics of web development forced us to tackle the phishing problem first - identity and authentication (AuthN) get the budget and attention. Passkeys might finally kill credential theft. Cool. But authentication is the easy problem. Authorization (AuthZ) is where we keep failing. The reality? All the YubiKeys and passkeys in the world won’t save you if a new user can access your admin panel by tweaking a role in their JWT. If anyone can view customer data by incrementing an ID in the API call, then it’s all for naught.
Perhaps, we’re close to getting “who are you?” right, but we still can’t consistently answer “What are you allowed to do?”
Injection still works :/
What’s fascinating about injection vulnerabilities is that we continue to make this mistake. Just as we’ve wrapped our heads around the ramifications of a given query technology, we invent a new one with a whole new set of injection primitives to worry about:
- 2004 - SQL databases were the norm → SQLi was rampant
- 2010 - XML-RPC was common → XXE attacks emerged
- 2015 - NoSQL databases became mainstream → NoSQL injection appeared
- 2020 - GraphQL was everywhere → We stacked NoSQL injection with GraphQL-specific query manipulation
- 2025 - LLMs are in production → Prompt injection, RAG poisoning, and indirect prompt injection are the new frontier
The underlying problem never changed: we’re still concatenating untrusted input into interpreters. We just keep inventing new interpreters. In 2004, it was "SELECT * FROM users WHERE id=" + userInput.
In 2025, it’s f"Answer this question using the following context: {userInput}". Same vulnerability. Different syntax. We learned to parameterize SQL queries, but forgot the lesson when we moved to NoSQL, GraphQL, and now AI prompts.
Conclusion: What Does This Mean Beyond 2025?
Twenty years of OWASP Top 10 data reveal something uncomfortable: we’re not improving at the fundamentals. We’re getting better at building complex systems that distribute the same old vulnerabilities across more layers.
Will AI in the form of LLM-based tools help us? That remains to be seen; however, I remain skeptical of this, given that broken access control is still at the top. BAC issues stem from a lack of understanding or testing of the business rules unique to the application being built. That is to say, you can’t prompt for what you don’t know to ask for in the first place, and the LLM won’t inherently detect every single RBAC rule your organization has come up with, at least not unless the LLM has direct access to that information, which seems unlikely to me. This is why humans will continue to be heavily involved in creating software well into the future.
For Defenders
The good news is that the AppSec playbooks from 2004 largely still work. SQL injection prevention, access control validation, and input sanitization aren’t outdated techniques. They’re eternal truths we keep forgetting.
The challenge is that you now need to apply those fundamentals across:
- 50 microservices
- 400 npm dependencies
- 12 cloud services
- AI prompts that look like natural language but behave like SQL queries
Actionable advice
- Shift left, but verify right: DevSecOps is great, but runtime monitoring caught SolarWinds, CodeCov, and dozens of supply chain attacks that passed all the CI checks
- Assume compromise in your dependencies: Pin versions, use SBOMs, monitor for behavioral changes
- Log like someone’s life depends on it: Because in healthcare, finance, and critical infrastructure, it actually might.
For Developers
You’ve inherited 20 years of technical debt disguised as “best practices.” From one of the old guard - I am sorry.
The uncomfortable truth for that npm package you installed? You’re trusting 79 third-party packages and 39 maintainers on average. That GraphQL endpoint? It’s just SQL injection with extra steps. That LLM feature? It’s user input concatenation all over again.
First Principles still matter
- Understand, don’t just use: Frameworks protect you until they don’t. Know why parameterized queries work, not just how to use an ORM
- Treat AuthZ like AuthN: You wouldn’t skip password validation. Stop skipping resource ownership checks
- Your code will be attacked: Design with that assumption. Write logs that help future-you during an incident at 3 am
- Supply chain hygiene: Review your dependencies like you review your own code. That leftpad incident wasn’t a fluke; it was a warning
The mantra: If you’re concatenating untrusted user input into anything that interprets it, you have the makings for an injection vulnerability. Validate the inputs, if you can find segregation approaches (like parameterization), to ring fence data from code construction, then use it! If such features don’t exist, this is a problem worth solving.
For Leadership
Here’s what 20 years of data actually tells you:
1. Security isn’t getting easier**
You can’t “buy security” - never could. That SAST tool, WAF, or SIEM? They’re necessary, but insufficient. Security is about your people:
- Developer training (they’re shipping the vulnerabilities)
- Architecture decisions (microservices = more attack surface)
- Supply chain verification (your code is 5% of your application)
- Incident response and threat hunting capabilities (you will be breached, but can you detect it?)
2. The fundamentals haven’t changed, but the economics have
In 2004, a breach resulted in some unfavorable press. In 2025, it means:
- GDPR/DORA/CCPA/HIPAA fines (4% of global revenue)
- Class action lawsuits
- Ransomware payments
- Supply chain liability (you breached your customers, too)
- Millions wiped off stock prices overnight
The ROI on basic security hygiene has never been higher.
3. Your developers are your security team (whether you like it or not)
Every line of code is a security decision. Every dependency is a trust decision. Every API endpoint is an attack vector. You can hire all the security engineers you want, but if your 50 developers ship 1,000 commits per week, security-by-review doesn’t scale.
Investment priorities:
- Training: Not compliance checkbox training. Real, practical secure coding for your stack
- Tooling: SAST/DAST/SCA that developers actually use (not just buy)
- Culture: Making security a feature requirement, not a post-release patch
- Observability: You can’t defend what you can’t see. Log aggregation, SIEM, and actual human analysis
Call to Action: How Does Your Application Stack Up?
Here’s your mission if you choose to accept it.
- Take 30 minutes: Walk through the OWASP Top 10 2025 RC1 and honestly assess which apply to your application
- Check your dependencies: Run
npm auditor equivalent. How many HIGH/CRITICAL vulnerabilities are you shipping? - Test your logging: Simulate an attack. Can you detect it? Can you trace it? Can you respond to it?
- Review your CI/CD: Can you prove what went into your last build? Do you have integrity checks?
- Audit one critical endpoint: Pick your most sensitive API. Check for:
- Broken access control (can user A access user B’s data?)
- Injection vectors (are you sanitizing/parameterizing inputs?)
- Logging (would you know if this endpoint was being abused?)
Then ask yourself: If this application were breached tomorrow, would we:
- Know about it within hours (not months)?
- Understand how they got in?
- Be able to prove what data was accessed?
- Have a response plan that doesn’t start with “panic”?
If you answered “no” to any of those, start with the OWASP Top 10. It’s been telling us the same story for 20 years.
A Final Thought
The OWASP Top 10 isn’t a prediction of the future. It’s a reflection of our past.
Buffer overflows dropped off not because we got smarter, but because we moved to languages that wouldn’t let us make that mistake. SQL injection is still #3 not because it’s hard to prevent, but because we keep forgetting to prevent it.
That’s up to us.
Thanks for reading. If you found this useful, consider sharing it with your team. And if you’re working on securing applications, you’re not alone—the OWASP community is there to help. Check out owasp.org for resources, tools, and that Top 10 list we’ve been talking about.
Stay safe out there. And for the love of all that is good, parameterize your queries!
Tags:
