5019b13e96214669a2ff78bdab77d0f0

OWASP Top Ten Data Collection is Open

Fri, 19 Jan 2024 14:45:09 GMT

Data Collection: Now - December 2024

It's time to get machinery running again and figure out what the next OWASP Top Ten is going to look like for 2024. The last two cycles have worked out well for us, so we are going to continue to use the same process for data collection and the same templates as the 2021 collection process. You can find more details in Github or in the README folder behind the bit.ly link which points to a SharePoint folder that will automatically move submissions to Azure blob storage for processing.

Templates: https://github.com/OWASP/Top10/tree/master/2024/Data

Contribution Process

There are a few ways that data can be contributed:

Email a CSV/Excel/JSON file with the dataset(s) to brian.glas@owasp.org
Upload a CSV/Excel/JSON file to https://bit.ly/OWASPTop10Data

Contribution Period

We plan to accept contributions to the Top 10 2024 during Jun-Dec of 2024 for data dating from 2021 to current.

Data Structure

We have both CSV and JSON templates to aid in normalizing contributions: https://github.com/OWASP/Top10/tree/master/2024/Data

The following data elements are *required or optional:

Per DataSet:

Contributor Name (org or anon)
Contributor Contact Email
Time period (2023, 2022, 2021)
*Number of applications tested
*CWEs w/ number of applications found in
Type of testing (TaH, HaT, Tools)
Primary Language (code)
Geographic Region (Global, North America, EU, Asia, other)
Primary Industry (Multiple, Financial, Industrial, Software, ??)
Whether or not data contains retests or the same applications multiple times (T/F)

If a contributor has two types of datasets, one from HaT and one from TaH sources, then it is recommended to submit them as two separate datasets.

Analysis
We will conduct analysis of the data, in a similar manner as the 2021 and hope to also include some trending data over both the 2021 and 2024 collection time periods.

Timeline
Data Collection: Jun - Dec
Analysis: Early 2025
Draft: Early 2025
Release: First half of 2025

The Release of the OWASP Top 10:2021

Fri, 24 Sep 2021 04:49:21 GMT

Released: September 24, 2021

The leadership team is pleased to announce the release of the OWASP Top 10:2021 on September 24, 2021

The Top 10:2021 can be found at https://owasp.org/Top10

We are still working on the downloadable PDF and some infographics as well.

Translations have begun, if you would like to contribute please visit the #top-10-translations in the OWASP Slack.
If you need to join, you can here: https://owasp.org/slack/invite

New in the Top 10:2021 is our own logo and icons thanks to Hugo Costa!

OWASP Top Ten September Update

Sun, 12 Sep 2021 12:55:30 GMT

Draft Release for Review

The draft release of the OWASP Top 10 2021 has been published for review: https://owasp.org/Top10

Feedback, comments, issues can all be filed in our GitHub project: https://github.com/OWASP/Top10/issues

A mammoth THANK YOU to everyone that contributed data, time, thoughts, and anything else.

Hundreds of hours went into the data collection, analysis, and initial draft. Here is a high level overview of what is in the draft.

What's changed in the Top 10 for 2021

There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021.

A01:2021-Broken Access Control moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 CWEs mapped to Broken Access Control had more occurrences in applications than any other category.
A02:2021-Cryptographic Failures shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.
A03:2021-Injection slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition.
A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.
A05:2021-Security Misconfiguration moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it's not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.
A06:2021-Vulnerable and Outdated Components was previously titled Using Components with Known Vulnerabilities and is #2 in the industry survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any CVEs mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
A07:2021-Identification and Authentication Failures was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from CVE/CVSS data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.
A09:2021-Security Logging and Monitoring Failures was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn't well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
A10:2021-Server-Side Request Forgery is added from the industry survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the industry professionals are telling us this is important, even though it's not illustrated in the data at this time.

We will be accepting feedback as long as we can and plan to release the final version as part of the OWASP 20th Anniversary on September 24, 2021.

OWASP Top Ten 2021 August Update

183:859943589 (Brian Glas) — Thu, 19 Aug 2021 22:49:40 GMT

Update time, we are nearing the finish line.

All told for the data collection; we have thirteen contributors and a grand total of 515k applications represented as non-retests (we have additional data marked as retest, so it's not in the initial data for building the Top 10, but will be used to look at trends and such later).

We asked ourselves whether we wanted to go with a single CWE for each "category" in the OWASP Top 10. Based on the contributed data, this is what it could have looked something like:

1. Reachable Assertion

2. Divide by Zero

3. Insufficient Transport Layer Encryption

4. Clickjacking

5. Known Vulns

6. Deployment of the Wrong Handler

7. Infinite Loop

8. Known Vulns

9. File or Dir Externally Accessible

10. Missing Release of Resources

And that is why we aren't doing single CWEs from this data. It's not helpful for awareness, training, baselines, etc. So we confirmed that we are building risk categories of groups of related CWEs. As we categorized CWEs, we ran into a decision point, focusing more on Root Cause or Symptom ?

For example, Sensitive Data Exposure is a symptom, and Cryptographic Failure is a root cause. Cryptographic Failure can likely lead to Sensitive Data Exposure, but not the other way around. Another way to think about it is a sore arm is a symptom; a broken bone is the root cause for the soreness. Grouping by Root Cause or Symptom isn't a new concept, but we wanted to call it out. Within the CWE hierarchy, there is a mix of Root Cause and Symptom weaknesses. After much thought, we focused on mapping primarily to Root Cause categories as possible, understanding that sometimes it's just going to be a Symptom category because it isn't classified by root cause in the data. A benefit of grouping by Root Cause is that it can help with identification and remediation as well.

We spent a few months grouping and regrouping CWEs by categories and finally stopped. We could have kept going but needed to stop at some point. We have ten categories with an average of almost 20 CWEs per category. The smallest category has one CWE, and the largest category has 40 CWEs. We've received positive feedback related to grouping like this as it can make it easier for training and awareness programs to focus on CWEs that impact a targeted language or framework. Previously we had some Top 10 categories that simply no longer existed in some languages or frameworks, and that would make training a little awkward.

Finding Impact (via Exploit and Impact in CVSS)

In 2017, once we defined Likelihood using incidence rate from the data, we spent a good while discussing the high-level values for Exploitability , Detectability , and Technical Impact . While four of us used decades of experience to agree, we wanted to see if it could be more data-driven this time around. (We also decided that we couldn't get Detectability from data so we are not going to use it for this iteration.)

We downloaded OWASP Dependency Check and extracted the CVSS Exploit and Impact scores grouped by related CWEs. It took a fair bit of research and effort as all the CVEs have CVSSv2 scores, but there are flaws in CVSSv2 that CVSSv3 should address. After a certain point in time, all CVEs are assigned a CVSSv3 score as well. Additionally, the scoring ranges and formulas were updated between CVSSv2 and CVSSv3.

In CVSSv2, both Exploit and Impact could be up to 10.0, but the formula would knock them down to 60% for Exploit and 40% for Impact. In CVSSv3, the theoretical max was limited to 6.0 for Exploit and 4.0 for Impact. We analyzed the average scores for CVSSv3 after the changes to weighting are factored in; and the Impact scoring shifted higher, almost a point and a half on average, and exploitability moved nearly half a point lower on average.

There are 125k records of a CVE mapped to a CWE in the NVD data extracted from OWASP Dependency Check at the time of extract, and there are 241 unique CWEs mapped to a CVE. 62k CWE maps have a CVSSv3 score, which is approximately half of the population in the data set.

For the Top Ten, we calculated average exploit and impact scores in the following manner. We grouped all the CVEs with CVSS scores by CWE and weighted both exploit and impact scored by the percentage of the population that had CVSSv3 + the remaining population of CVSSv2 scores to get an overall average. We mapped these averages to the CWEs in the dataset as Exploit and Impact scoring for the other half of the risk equation.

We agreed that we would use the high watermark of the incidence rate for each grouping to help set the order of the 2021 Top 10. The results of this will be released shortly as our target release date is Sept 24, 2021, to align with the OWASP 20th Anniversary.

OWASP Top Ten 2021 April Update

Sun, 25 Apr 2021 21:01:55 GMT

We wanted to send everyone updates on our progress related to data analysis, survey, and format of the OWASP Top Ten 2021.

The Data

We are wrapping up the analysis of the data submissions, which is more intensive this cycle than before. Previous data calls for the Top Ten were limited to requesting ~30 CWEs with an option to write in more. While this would make analysis more straightforward, it has the potential not to show what’s going on in the wild. For this Top Ten cycle, we changed it up and asked for all the CWEs that organizations would map to their findings. Boy, did we get what we asked for; instead of 30 CWEs of data to process, we have data for ~380 unique CWEs to review and analyze. In 2017 we had data submitted that represented testing of ~144k applications; for 2021, we are looking at ~500k applications worth of testing data.

Similar to the last Top Ten, we are looking at incidence rate instead of frequency. We do this for two reasons. The frequency will allow a small number of risk categories to dominate the data analysis and hide more impactful issues. For example, if we have a population of 1000 applications and ten of them have an average of 4,000 instances of Cross-site Scripting (XSS) and 200 applications with an average of five instances of SQL Injection the frequency data might look like this:

Cross-site Scripting: 97.6% of vulnerabilities

SQL Injection: 2.4% of vulnerabilities

If we look at incidence rate, or how many applications in the population have a particular vulnerability, this provides a very different perspective (and arguably more accurate for measuring risk).

SQL Injection: 20% incidence rate

Cross-site Scripting: 1% incidence rate

One other item we are adding to this year’s analysis is the concept of “confidence.” When each organization sent us data, we had them send it in the form of:

“X apps were tested for Y CWE, and Z apps were positive.”

We can calculate an incidence rate for that population tested. However, we also have a larger population overall, and not all of these applications may have been tested for that type of vulnerability; this is where “confidence” factors into the equation. If we have a CWE with an incidence rate of 50%, but the total number of the overall population tested for it is just 1%, we determine there is lower confidence for that incidence rate. On the other side, if we have a CWE with an incidence rate of .67%, but the total number of the overall population tested for it is 92%, we have high confidence that it’s accurately representing what’s in the wild.

Side note: Yes, you can argue against this by bringing up factors like quality of test cases, differences in testing between organizations, and so on. However, trying to get to that level of detail is far beyond what a group of volunteers can be reasonably expected to undertake at this time.

The Survey

Many thanks to everyone that took a little time from their day and completed the survey for the Top Ten! Without you, there are no results to analyze :-D. We finished with a total of 437 responses, which is close to the 516 we had in 2017. Reviewing the timeline of submissions, nothing looks strange or out of the ordinary, so no real worries about someone trying to game the survey.

As we have mentioned before, the reason for the survey is that solely relying on testing data has some limitations and blind spots. We will only get a volume of data on vulnerabilities found once we figure out how to manually test for them, convert that to automated testing, and scale it beyond a few organizations. As a result, we have a time lag, and looking at just the data will always be looking at some point in the past. The time lag is why we create the survey for people in the front lines to share what they believe are essential categories based on their experiences. We will use the survey results to pull in up to two categories that we don’t have data (yet) to represent.

I would like to look at some of the metadata of who completed the survey, as I think it holds a lot of insight and value. All the metadata questions were optional; the only required question was for ranking the top four categories one thinks are worthy of consideration in the Top Ten; thus, not all of these answers will have 437 responses.

For the first question about experience, the distribution is reasonably balanced; we can see the industry is aging which is no surprise. One takeaway from this distribution that we should pay attention to is the 28.5% of 0-3 years. The longer we are in the industry, the further from our origins we get, and we tend to forget that new people are joining our industry daily. We need to make it a priority to build paths to help group and mature people joining our ranks; otherwise, we will not be able to make the progress we dearly need to help improve security.

Looking at the position of people completing the survey, in-house security is the largest group, with consultants at number two. We support the write-in option for most of these questions because the industry is still a long way from maturing, so we can’t possibly provide every viable option to select. 6.6% of responses wrote in something other than the two options. We have representation from both Professors and Students, people who wear multiple hats, and others.

The primary role question usually receives the most write-in options, and for a good reason, we don’t have a good role standardization in our industry. There is quite a laundry list of submitted roles that people are assigned.

Advisor / Analyst

Developer / Engineer

Tester

Monitor / Responder

Management

Architect

Researcher

Consultant

Advisor, Tester, Management, Respon…

Audit

Vuln Researcher

Secure Coding Educator

Vendor / Advisor

security architect

Hacker

Multiple

Technical Evangelist - advisory and training fit most closely

Security Architect

Information Security Architect

Security engineer

Red Team

The last metric to look at is how the Top Ten impacts work. The respondents are allowed to select all that apply, as the Top Ten can be used for many things and explains why it doesn’t add up to 100%. The number one answer is “It helps provides structure for standards, requirements, security tests, test results, etc.,” with 72.8% of the respondents selecting that option. Number two is “Mostly for the education of developers,” and number three is “We build processes around it.”

Formatting

For this round of updates for the OWASP Top Ten, we plan to focus on a more mobile friendly version of the output. We also plan to update graphics and provide more supporting content and links from the Top Ten. More updates to follow in the near future.

Building the 2021 Top Ten Survey

Tue, 02 Feb 2021 14:17:47 GMT

Help build the survey for the 2021 Top Ten

As we're putting together the survey for the next Top Ten so that you can help pick two vulnerability categories or risks for inclusion, we face the challenge of what to include in the survey.

Remember, for the Top 10 2017, we determined as a team that we would pick eight risks from the data submitted and two risks from a survey that would be completed by industry practitioners. We did this as the data will always show us information from the past and is only as good as the testing coverage from the submitting organizations. The hope was that the practitioners in the trenches would help determine a couple of risks that might not show up in the data yet.

What this also means is that the two risks that were selected by survey in 2017 are on the block again this time around when we ask you to pick again. Now, there is the possibility that testing has caught up since the first survey and Deserialization and Insufficient Logging and Monitoring might be able take their place in the data, they might not, that remains to be seen.

---------------------------------------------------------

Below is the history and process for creating this survey, it sums up with a call to action. If you have a CWE that you think should be added to the survey, please open an issue in the Top Ten GitHub Repo with the label " 2021-Survey " and we'll review and possibly add it to the survey: https://github.com/OWASP/Top10/issues/new

---------------------------------------------------------

Here is a little bit of background from last time we did this; some of you remember, some don't, and some were not working in this industry yet.

In 2017, we submitted a survey with the following CWEs

CWE-799	Improper Control of Interaction Frequency (Anti-Automation)
CWE-223/778	Insufficient Logging and Monitoring
CWE-918	Server-Side Request Forgery (SSRF)
CWE-915	Mass Assignment
CWE-829	Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content)
CWE-639	Authorization Bypass Through User-Controlled Key (IDOR & Path Traversal)
CWE-611	Improper Restriction of XML External Entity Reference ('XXE')
CWE-601	Unvalidated Forward and Redirects
CWE-502	Deserialization of Untrusted Data
CWE-451	User Interface (UI) Misrepresentation of Critical Information (Clickjacking and others)
CWE-400	Application Denial of Service
CWE-359	Exposure of Private Information ('Privacy Violation')
CWE-310/311/312/326/327	Cryptographic Failures

We asked everyone to rank their top four choices (1-4), then scored them to see what you all felt where the most important. We had 550 responses to the survey. The end results looked like this:

Rank	Vulnerability Categories	Score
1	Exposure of Private Information ('Privacy Violation') [CWE-359]	748
2	Cryptographic Failures [CWE-310/311/312/326/327]	584
3	Deserialization of Untrusted Data [CWE-502]	514
4	Authorization Bypass Through User-Controlled Key (IDOR & Path Traversal) [CWE-639]	493
5	Insufficient Logging and Monitoring [CWE-223 / CWE-778]	440
6	Server-Side Request Forgery (SSRF) [CWE-918]	390
7	Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content) [CWE-829]	351
8	Improper Restriction of XML External Entity Reference ('XXE') [CWE-611]	300
9	Application Denial of Service [CWE-400]	292
10	Unvalidated Forward and Redirects [CWE-601]	252
11	User Interface (UI) Misrepresentation of Critical Information (Clickjacking and others) [CWE-451]	174
12	Improper Control of Interaction Frequency (Anti-Automation) [CWE-799]	126
13	Mass Assignment [CWE-915]	76

After reviewing which categories would already be covered by data, the end result were the additions of

- A8-2017 Insecure Deserialization

- A10-2017 Insufficient Logging and Monitoring

Especially A10 would be unlikely to show up in the data set as that CWE is rarely reported by the assessment testing at the time and is fairly difficult to find in an automated fashion. But that's why we have this survey to add to the data collection, because the data can't tell us everything we need to know.

Also in the 2017 survey, we asked respondents to tell us what they think might need to be included in the next Top Ten.

These are the summarized results:

From 2017 Survey

Session Fixation – (Already in Top 10 2017)
CORS Misconfiguration - (Already in Top 10 2017)
Architecture/Design Issues
Components with known Vulns - (Already in Top 10 2017)
Private Data Exposure - (Already in Top 10 2017)
Logic flaws
Template Injection
RCE through XSS in RPC
Attacks against template engines
EL/OGNL/etc injections
Cloud Configuration Failures - (Already in Top 10 2017)
SubDomain Takeovers
Missing business logic validation
API AuthN/AuthZ – (API Top 10 2019)
Logic flow bypass
Protecting sensitive pages from automation
Malicious File Upload
Slow/lack of process to update apps
Web Cache Deception
API related weaknesses – (API Top 10 2019)
Privacy Related - (Already in Top 10 2017)
SSRF
OAuth token vulns (clientside heavy Auth)
Excessive 3rd party JS live inclusion

Though I'm pretty sure the best answer was: "One does not simply predict TOP 10 of vulnerability categories for three years ahead."

Now that we have covered the history, time to move forward to the here and now.

As we look to what may be in the next survey, there are considerations to take into account. We can look at the CWE Top 25 published by Mitre.

https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html

Rank ID-Name
[1] CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
[2] CWE-787 Out-of-bounds Write
[3] CWE-20 Improper Input Validation
[4] CWE-125 Out-of-bounds Read
[5] CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
[6] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
[7] CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
[8] CWE-416 Use After Free
[9] CWE-352 Cross-Site Request Forgery (CSRF)
[10] CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
[11] CWE-190 Integer Overflow or Wraparound
[12] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
[13] CWE-476 NULL Pointer Dereference
[14] CWE-287 Improper Authentication
[15] CWE-434 Unrestricted Upload of File with Dangerous Type
[16] CWE-732 Incorrect Permission Assignment for Critical Resource
[17] CWE-94 Improper Control of Generation of Code ('Code Injection')
[18] CWE-522 Insufficiently Protected Credentials
[19] CWE-611 Improper Restriction of XML External Entity Reference
[20] CWE-798 Use of Hard-coded Credentials
[21] CWE-502 Deserialization of Untrusted Data
[22] CWE-269 Improper Privilege Management
[23] CWE-400 Uncontrolled Resource Consumption
[24] CWE-306 Missing Authentication for Critical Function
[25] CWE-862 Missing Authorization

For a number of reasons, I disagree with this list; but that’s not the point. I’m trying to find CWEs that may exist, but aren’t really easily testable or are new enough that there aren’t many tests so I can add them to the survey to see if other in the industry think they have risen to that level of importance.

My goal for CWEs on the survey are to list CWEs that contain one or more of the following:

Hard to test: these are risk that are real, but unlikely to be exhibited in the data
Emerging risks: these are newer that there isn’t good testing coverage yet (usually at least a couple year lag)
TBD?

With those goals in mind, here is the draft of the Top 10 2021 Survey for feedback:

#	CWE	Note
1	Insufficient Logging and Monitoring [CWE-223/778]	Current Top 10, important, and hard to test for.
2	Server-Side Request Forgery (SSRF) [CWE-918]	Might be in the data this cycle, wasn’t last; but was hot in 2017-2018
3	Mass Assignment [CWE-915]	From 2017 Survey
4	Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content) [CWE-829]	With the increased dynamic integration of web content, this is ever growing; but may not really be tested for.
5	Unvalidated Forward and Redirects [CWE-601]	From 2017 Survey and additional risks to consider
6	Improper Control of Interaction Frequency (Anti-Automation) [CWE-799]	From 2017 Survey and additional risks to consider
7	Improper Restriction of Operations within the Bounds of a Memory Buffer [CWE-119]	From CWE Top 25 2020 and parent of CWE-125/CWE-787 aka Buffer Overflow and related
8	Unrestricted Upload of File with Dangerous Type [CWE-434]	In CWE Top 25 2020 and additional risks to consider 2017
9	Cross-Site Request Forgery (CSRF) [CWE-352]	Former Top 10 and in additional risks to consider 2017
10	Excessive Attack Surface [CWE-1125]	Testing the water for branching into a little more architecture/design related
11	Use of Unmaintained Third Party Components [CWE-1104]	Finally have an official CWE for this one
12	Inconsistency Between Implementation and Documented Design [CWE-1068]	Should we consider some more architectural risks? Incomplete Design Documentation [CWE-1110] and Missing Documentation for Design [1053]
13	Deserialization of Untrusted Data [CWE-502]	Current Top 10, didn’t seem to have a lot of testing
14	Unprotected Storage of Credentials [CWE-256]	It might be in the data, but may also be a hot enough topic to stand on its own.

There is nothing for API specific as we have an OWASP Top 10 API 2019 already and I don’t see a need to duplicate any of that work. Similarly, we have IoT and Mobile Top 10s, so no need to go there either.

I plan to use a similar format for the survey with some base demographic information and having people pick their top four.

This worked well last time and allows for a good understanding of priorities from a varied audience.

If you have a CWE that you think should be added to the survey, please open an issue in the Top Ten GitHub Repo with the label " 2021-Survey " and we'll review and possibly add it to the survey: https://github.com/OWASP/Top10/issues/new