Twenty Years of the OWASP Top 10: How Web Threats Evolved from 2003 to 2025
1. Introduction
In the early days of the Web, an HTML form could only send a handful of fields to a CGI script. Thirty years later, every browser session opens dozens of API calls, talks to microservices and consumes code from libraries loaded on the fly.
Over the years, the attack surface has grown more complex, bringing new attack vectors with it. The security community needed reference points to classify and categorize these emerging attacks.
That is the context in which OWASP has been publishing its Top 10 since 2003: a ranking of the most common web vulnerabilities.
The goal of this article is to retrace twenty years of web threat evolution through the lens of OWASP, in order to understand which factors mattered most. We will then try to extract the key elements likely to shape web security in the years ahead.
2. Introducing the OWASP "Top 10"
The Open Worldwide Application Security Project (OWASP) is a non-profit foundation and worldwide community founded in 2001 and dedicated to improving software security.
It publishes open, vendor-neutral resources: the WSTG (testing guide), the ASVS (verification standard), various tools, and the family of Top 10 lists (Web, API, Mobile, AI/LLM), all meant to help anyone secure their applications.
The Web Top 10 serves as an awareness baseline that ranks the most critical web application risks, based on incident data, security testing results and expert feedback.
A new edition comes out every few years: 2003, 2004, 2007, 2010, 2013, 2017 and 2021 (the latest stable version at the time of writing). An update is generally expected on a 3-4 year cycle.
For example, the most recent Top 10 covers the following risks:
| Code | Title | Summary |
|---|---|---|
| A01 | Broken Access Control | Access and authorization can be bypassed (permissions poorly enforced server-side). |
| A02 | Cryptographic Failures | Sensitive data poorly protected (misused or misconfigured cryptography). |
| A03 | Injection | Code injected through user input (SQL/NoSQL/LDAP/OS, and so on). |
| A04 | Insecure Design | Design flaws; abuse scenarios that were never anticipated. |
| A05 | Security Misconfiguration | Poor configuration of applications, servers, platforms or headers. |
| A06 | Vulnerable & Outdated Components | Vulnerable or outdated components and versions in the software supply chain. |
| A07 | Identification & Authentication Failures | Weak authentication and session management. |
| A08 | Software & Data Integrity Failures | Compromised integrity of dependencies, builds, CI/CD pipelines and updates. |
| A09 | Security Logging & Monitoring Failures | Insufficient logging and detection to spot and investigate attacks. |
| A10 | Server-Side Request Forgery (SSRF) | The server sends unintended network requests to internal or external targets. |
But getting there took eighteen years, marked by major shifts in the Top 10, as the following image illustrates.
3. Timeline
2003 - 2004
The era of unvalidated input and XSS
The first two editions of the Top 10, published in 2003 and 2004, reflect a Web still largely built on homegrown code, with CGI/PHP scripts and ad hoc assemblies. Input validation and session management were poorly understood. Unsurprisingly, the Unvalidated Input category topped the ranking, ahead of authentication and access control weaknesses and XSS.
The volume of vulnerabilities was high and exploitation often trivial. The typical attacker was an opportunist or a novice, armed with scanners and public exploits. Their goals: visibility (defacement), light denial of service, and basic takeover (hosting pages or sending spam).
One peculiarity of 2003: the presence of buffer overflows in a supposedly "Web" ranking, a sign that exposed C/C++ parsers and modules at the core of applications remained notable weak points.
2005 - 2007
Web 2.0, AJAX, and XSS/CSRF/IDOR vulnerabilities
With the rise of Web 2.0 and AJAX (popularized in 2005), applications became interactive without page reloads. User experience improved, and so did the browser-side attack surface.
In 2007, the OWASP Top 10 put XSS in first place, followed by Injection, Malicious File Execution, IDOR and CSRF. The last two were considered especially critical: IDOR highlighted the risks of using predictable identifiers, while CSRF exposed flaws caused by poor session state handling.
The prominence of Malicious File Execution was driven mostly by PHP Remote File Inclusions; the allow_url_include=Off default introduced in PHP 5.2 and the growing maturity of web frameworks would later push this family of flaws into decline.
The attacker profile shifted as well: the target was no longer just defacement, but also the theft of personal data and the abuse of authenticated actions.
2010 - 2013
Configuration, vulnerable components and growing complexity
Between 2010 and 2013, the Top 10 evolved to reflect a more industrialized Web: applications now relied on frameworks and third-party libraries, which changed the nature of the flaws.
The 2010 edition introduced Security Misconfiguration and Failure to Restrict URL Access, underscoring that security depends not only on code but also on server and framework settings. The arrival of secure defaults (such as CSRF protection enabled out of the box in Django 1.2 in 2010) illustrates this shift toward more disciplined development practices.
In 2013, two new entries marked an important milestone: the arrival of Using Components with Known Vulnerabilities, a direct reflection of the growth of dependency ecosystems (npm, Maven, Bower...). The risk tied to software supply chains became tangible, later embodied by the Equifax breach (2017) exploiting Apache Struts (CVE-2017-5638).
2017 - 2021
APIs, software integrity and cloud risks
The 2017 edition reflects the rise of APIs and distributed architectures. Two new categories appeared: XML External Entities (XXE), tied to overly permissive XML parsers, and Insecure Deserialization, exploitable in Java or PHP frameworks. The edition also introduced Insufficient Logging & Monitoring, acknowledging that attacks often go unnoticed for lack of detection. Meanwhile, Broken Access Control climbed up the ranking, foreshadowing the API era...
In 2021, the hierarchy changed dramatically: Broken Access Control moved into first place, while XSS was folded into the broader Injection category. Two new entries widened the perspective: Insecure Design, which pushes teams to build security in from the design stage, and Software & Data Integrity Failures, a reminder of the risks tied to CI/CD pipelines and critical updates. The year was marked by incidents such as SolarWinds (2020) and Log4Shell (2021)...
4. Notable factors
From simple websites to distributed ecosystems.
In twenty years, we went from the standalone "website" to architectures made of APIs, microservices and partner integrations. Every new component opens another door, and with it more chances to miss a control.
Hardening by default... and attacks moving elsewhere.
Browsers and frameworks fixed a share of the classic mistakes (output escaping, CSRF, security headers). Attackers therefore moved toward whatever escapes automatic protections: authorization (who can do what, on which object) and business logic, but sometimes also more complex flaws such as deserialization attacks.
The explosion of dependencies and the supply chain.
Our applications rest on dozens of libraries and third-party scripts. A flaw in a component or a CI/CD pipeline propagates to the entire application. Security is no longer just about "writing good code": it means managing a living inventory and the trust placed in everything we integrate.
DevOps and cloud: speed plus configuration.
Continuous delivery and the cloud speed up innovation, but risk shifts toward misconfigurations (overly broad permissions, exposed secrets, open storage buckets) and operational hygiene.
You cannot act on what you cannot see.
Modern attacks are quiet. Without reliable logs, meaningful metrics and useful alerts, incidents are discovered too late. Observability becomes a business capability: measure, detect, respond.
Key takeaway: risk has shifted from the "raw" bug toward authorization, configuration and the supply chain, in systems that are more distributed and faster-moving than ever.
5. Looking ahead
OWASP Top 10:2025: sharpening the "Web" lens.
The next edition of the Top 10, expected in late 2025, should extend the trends of recent years: Broken Access Control has every reason to stay on top, while the injection family remains a recurring thread. The software supply chain and API/cloud security should, for their part, gain in granularity.
Generative AI: spectacular productivity, very real security debt.
Coding assistants speed up delivery, but they can introduce outdated patterns or skip authorization checks. The remedy is not to slow adoption but to industrialize it: systematic scanning (SAST/DAST/secrets/IaC), policy as code, security testing and traceability of AI suggestions.
Content that attacks the code: "indirect prompt injection", Web edition.
Going forward, applications will process external content, sometimes hostile, capable of manipulating application logic. The measures to plan for include a strict separation between data and instructions and tamper-proof logging.
HTTP/3: next-generation "desync" attacks.
The network stack is changing with multiplexing, a growing diversity of proxies and the rise of edge computing. Historical vulnerabilities are mutating under the influence of new parsers and CDN architectures. Testing will need to reproduce the full chain to detect inconsistencies.
An industrial front end under continuous control.
The future of the client-side Web does not lie in cutting back dependencies, but in tightening control: systematic adoption of SRI, Trusted Types enabled by default, automated script inventories, and real-time alerting.
In short: the major shifts on the Web do not come from new acronyms, but from authorization, integrity and parsing problems being transposed ever closer to the browser, the APIs and the edge.
6. Conclusion
In a little over twenty years, the "Top 10" has gone from filtering form fields to orchestrating global software chains. While injections never really disappeared, most of the danger has moved: from the line of code to design, then to the ecosystem.
Vigilance today no longer means simply patching a PHP file. It means knowing which building blocks make up your software, how they communicate and who operates them. Armed with this historical frame of reference, builders and auditors can better prioritize their efforts and narrow the gap between innovation and security.
Keep reading
Tell us about your project.
Let us talk through your needs and expectations and build the right service for you.

