This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Background OWASP Top Ten 2004 Project"
m |
m |
||
| Line 1: | Line 1: | ||
==Background== | ==Background== | ||
| − | The challenge of identifying the “top” web application vulnerabilitiesis a virtually impossible task. There is not even widespread agreement on exactlywhat is included in the term “web application security.” Some haveargued that we should focus only on security issues that affect developers writingcustom web application code. Others have argued for a more expansive definitionthat covers the entire application layer, including libraries, server configuration,and application layer protocols. In the hopes of addressing the most seriousrisks facing organizations, we have decided to give a relatively broad interpretationto web application security, while still keeping clear of network and | + | The challenge of identifying the “top” web application vulnerabilitiesis a virtually impossible task. There is not even widespread agreement on exactlywhat is included in the term “web application security.” Some haveargued that we should focus only on security issues that affect developers writingcustom web application code. Others have argued for a more expansive definitionthat covers the entire application layer, including libraries, server configuration,and application layer protocols. In the hopes of addressing the most seriousrisks facing organizations, we have decided to give a relatively broad interpretationto web application security, while still keeping clear of network and infrastructure security issues. |
Another challenge to this effort is that each specific vulnerability is uniqueto a particular organization’s website. There would be little point incalling out specific vulnerabilities in the web applications of individual organizations,especially since they are hopefully fixed soon after a large audience knows oftheir existence. Therefore, we have chosen to focus on the top classes, types,or categories of web application vulnerabilities. | Another challenge to this effort is that each specific vulnerability is uniqueto a particular organization’s website. There would be little point incalling out specific vulnerabilities in the web applications of individual organizations,especially since they are hopefully fixed soon after a large audience knows oftheir existence. Therefore, we have chosen to focus on the top classes, types,or categories of web application vulnerabilities. | ||
| Line 7: | Line 7: | ||
In the first version of this document, we decided to classify a wide range ofweb application problems into meaningful categories. We studied a variety ofvulnerability classification schemes and came up with a set of categories. Factorsthat characterize a good vulnerability category include whether the flaws areclosely related, can be addressed with similar countermeasures, and frequentlyoccur in typical web application architectures. In this version we are introducinga refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issuesfrom which security researchers can describe signatures in an XML format. | In the first version of this document, we decided to classify a wide range ofweb application problems into meaningful categories. We studied a variety ofvulnerability classification schemes and came up with a set of categories. Factorsthat characterize a good vulnerability category include whether the flaws areclosely related, can be addressed with similar countermeasures, and frequentlyoccur in typical web application architectures. In this version we are introducinga refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issuesfrom 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 | + | 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 prioritizethe top ten. However, for a number of reasons, this sort of measurement is notlikely to occur in the near future. |
| − | We recognize that there is no “right” answer for which | + | We recognize that there is no “right” answer for which vulnerability categories should be in the top ten. Each organization will have to think aboutthe risk to their organization based on the likelihood of having one of theseflaws and the specific consequences to their enterprise. In the meantime, weput this list forward as a set of problems that represent a significant amountof risk to a broad array of organizations. The top ten themselves are not inany particular order, as it would be almost impossible to determine which ofthem represents the most aggregate risk. |
The OWASP Top Ten project is an ongoing effort to make information about keyweb application security flaws available to a wide audience. We expect to updatethis document annually based on discussion on the OWASP mailing lists and feedbackto [email protected]. | The OWASP Top Ten project is an ongoing effort to make information about keyweb application security flaws available to a wide audience. We expect to updatethis document annually based on discussion on the OWASP mailing lists and feedbackto [email protected]. | ||
Revision as of 18:14, 19 May 2006
Background
The challenge of identifying the “top” web application vulnerabilitiesis a virtually impossible task. There is not even widespread agreement on exactlywhat is included in the term “web application security.” Some haveargued that we should focus only on security issues that affect developers writingcustom web application code. Others have argued for a more expansive definitionthat covers the entire application layer, including libraries, server configuration,and application layer protocols. In the hopes of addressing the most seriousrisks facing organizations, we have decided to give a relatively broad interpretationto web application security, while still keeping clear of network and infrastructure security issues.
Another challenge to this effort is that each specific vulnerability is uniqueto a particular organization’s website. There would be little point incalling out specific vulnerabilities in the web applications of individual organizations,especially since they are hopefully fixed soon after a large audience knows oftheir 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 ofweb application problems into meaningful categories. We studied a variety ofvulnerability classification schemes and came up with a set of categories. Factorsthat characterize a good vulnerability category include whether the flaws areclosely related, can be addressed with similar countermeasures, and frequentlyoccur in typical web application architectures. In this version we are introducinga refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issuesfrom 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 prioritizethe top ten. However, for a number of reasons, this sort of measurement is notlikely 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 aboutthe risk to their organization based on the likelihood of having one of theseflaws and the specific consequences to their enterprise. In the meantime, weput this list forward as a set of problems that represent a significant amountof risk to a broad array of organizations. The top ten themselves are not inany particular order, as it would be almost impossible to determine which ofthem represents the most aggregate risk.
The OWASP Top Ten project is an ongoing effort to make information about keyweb application security flaws available to a wide audience. We expect to updatethis document annually based on discussion on the OWASP mailing lists and feedbackto [email protected].
