This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Background OWASP Top Ten 2004 Project

Jump to: navigation, search


The challenge of identifying the “top” web application vulnerabilities is a virtually impossible task. There is not even widespread agreement on exactly what is included in the term “web application security.” Some have argued that we should focus only on security issues that affect developers writing custom web application code. Others have argued for a more expansive definition that covers the entire application layer, including libraries, server configuration, and application layer protocols. In the hopes of addressing the most serious risks facing organizations, we have decided to give a relatively broad interpretation to web application security, while still keeping clear of network and infrastructure security issues.

Another challenge to this effort is that each specific vulnerability is unique to a particular organization’s website. There would be little point in calling out specific vulnerabilities in the web applications of individual organizations, especially since they are hopefully fixed soon after a large audience knows of their existence. Therefore, we have chosen to focus on the top classes, types, or categories of web application vulnerabilities.

In the first version of this document, we decided to classify a wide range of web application problems into meaningful categories. We studied a variety of vulnerability classification schemes and came up with a set of categories. Factors that characterize a good vulnerability category include whether the flaws are closely related, can be addressed with similar countermeasures, and frequently occur in typical web application architectures. In this version we are introducing a refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issues from which security researchers can describe signatures in an XML format.

To choose the top ten from a large list of candidates has its own set of difficulties. There are simply no reliable sources of statistics about web application security problems. In the future, we would like to gather statistics about the frequency of certain flaws in web application code and use those metrics to help prioritize the top ten. However, for a number of reasons, this sort of measurement is not likely to occur in the near future.

We recognize that there is no “right” answer for which vulnerability categories should be in the top ten. Each organization will have to think about the risk to their organization based on the likelihood of having one of these flaws and the specific consequences to their enterprise. In the meantime, we put this list forward as a set of problems that represent a significant amount of risk to a broad array of organizations. The top ten themselves are not in any particular order, as it would be almost impossible to determine which of them represents the most aggregate risk.

The OWASP Top Ten project is an ongoing effort to make information about key web application security flaws available to a wide audience. We expect to update this document annually based on discussion on the OWASP mailing lists and feedbackto [email protected]