Etusivu Blogit OWASP Top 10 2021: is it the right direction?

OWASP Top 10 2021: is it the right direction?

Julkaistu 9.11.2021
Lukuaika noin 10 min

The OWASP Top 10 is undergoing some significant changes with the 2021 release – and many of these are not obvious.

The OWASP Top 10 2021 is out, and it brings a lot of changes. Some of these are obvious just by looking at the elements, but others show a further shift in focus for the Top 10 itself. The list has been undergoing a gradual reform that started in 2017 when they’ve set in stone the methodology and opened towards DevOps. Let’s see how this evolution continues in 2021.

The Top 10 – published by the Open Web Application Security Project community every three, occasionally four years – is probably the single best-recognized document in the world when it comes to software security. It distills the current state of web application security into an easily-digestible list of 10 issues that are useful to web application developers as well as security experts. For more insight on these topics, check out our articles on the OWASP Top 10 in general as well as the Open Web Application Security Project as a whole.

But of course, a top 10 list can never be complete. As newer versions of the Top 10 are released, they show a continuing tug-of-war between two different mindsets: should the Top 10 be ‘just’ a list of 10 concrete software vulnerabilities, or should it be a broad, all-encompassing list of security problems or threats?

Let’s take a look at the latest changes and what they mean for the future.

The new face of the Top 10

OWASP published the new OWASP Top 10 2021 on the 24th of September 2021. They modernized the presentation compared to the 2017 edition. Instead of a PDF, it is now a single web page with sub-pages for each entry; this also potentially makes it a living document, though we don’t expect the actual entries to change substantially. Let’s look at the new Top 10 through the mapping image from the document:

Source: https://owasp.org/Top10/assets/mapping.png

The OWASP Top 10 2021 has undergone some massive changes. Only 5 of the 10 categories from the 2017 Top 10 have survived, the other 5 are either new (like SSRF and Insecure Design), or a recombination of earlier Top 10 categories (such as Injection now encompassing Cross-Site Scripting as well). Let’s look at each entry in detail!

A01:2021 is Broken Access Control. The definition of the entry hasn’t changed from 2017, though now it encompasses many different issues related to access control issues, from path traversal to Cross-Site Request Forgery (CSRF). It has also risen from #5 to #1 based on the very high incidence rate of these issues in real-world applications.
A02:2021 is Cryptographic Failures. While the entry looks new, it’s really not; it’s just renaming Sensitive Data Exposure to the naming scheme it used in the pre-2013 versions of the Top 10 (i.e. Insecure Cryptographic Storage and Insufficient Transport Layer Protection). As before, this category is much more about the consequences of improper (or missing) use of cryptography than the root causes themselves.
A03:2021 is Injection. This class of vulnerabilities has been on the Top 10 since its inception and has been #1 since 2010. While for the best-known vulnerability in this category, SQL injection, we have some well-known best practices for some time, injection vulnerabilities are not going away – just look at the command injection in the Zoom breach or the OGNL injection in case of the Atlassian breach. The risk posed by this vulnerability type is higher than Broken Access Control and Cryptographic Failure, but the incidence rate is significantly lower than both, which explains its new position at #3. And of course, this category now includes cross-site scripting (XSS) as well, since it is technically an HTML injection vulnerability.
A04:2021 is Insecure Design. This is a completely new category in the OWASP Top 10 2021 and is the most controversial of all new additions: it moves away from secure implementation towards the need to design security into the system and following secure coding principles. This implies building security into the SDLC by adopting something like the OWASP Software Assurance Maturity Model (SAMM). We cover these in our article about secure coding practices. But this category contains a large variety of design flaws as well, such as CWE-312 Cleartext Storage of Sensitive Information (arguably sharing it with A02) and CWE-451 User Interface (UI) Misrepresentation of Critical Information.
A05:2021 is Security Misconfiguration. Moving up from the #6 spot due to an increased incidence rate, this category encompasses general issues – such as cookie misconfiguration – as well as issues related to misconfiguration of a specific platform or web server. Of special interest is XML External Entities (XXE, #4 in Top 10 2017) being folded into this category, as arguably the XXE vulnerability is a consequence of a misconfigured XML parser component, even though this particular configuration is of course on the devs’, and not on the ops’ side.
A06:2021 is Vulnerable and Outdated Components. Formerly known as Using Components with Known Vulnerabilities, it has climbed from #9 to #6. It is unique in the Top 10 in that it does not reference any specific vulnerabilities in CWE, and thus there is no way to assess its total risk – after all, this category is about vulnerability management of issues in third-party code that “may not be your fault but are definitely your problem”. It is clearly one of the ‘DevOps-focused’ categories, together with the previous Security Misconfiguration.
A07:2021 is Identification and Authentication Failures. Formerly known as Broken Authentication, it encompasses a very large variety of issues related to credential management, certificate issues, and session handling. It has fallen down significantly from its previous #2 position – mainly due to the prevalence of frameworks that prevent many of these vulnerabilities (or at least make it really hard for developers to commit them).
A08:2021 is Software and Data Integrity Failures. This is a new category on the list, and it covers many DevOps-related topics such as software updates and continuous integration and deployment (CI/CD) pipelines – not surprising in the wake of the SolarWinds Orion hack and similar attacks. The previous #8, Insecure Deserialization, was merged into this category since obviously the core of that problem is the deserialization of untrusted (non-integrity-protected) data. And we also have the Hafnium attacks against Microsoft Exchange that happened earlier this year to remind us that it is still relevant.
A09:2021 is Security Logging and Monitoring Failures. This is just a rename of Insufficient Logging & Monitoring, though there is an interesting change – it now directly covers CWE-117 Improper Output Neutralization for Logs, which itself can be considered a subclass of (CRLF) Injection. In addition to logging, it also emphasizes the importance of being proactive with monitoring to detect breaches early, as explained in our article on incident response.
A10:2021 is Server-Side Request Forgery (SSRF). SSRF is new to the OWASP Top 10 2021; it was added based on community vote as one of the ‘forward-looking’ elements. It is a vulnerability that allows an external attacker to force a server-side application to make an HTTP request to an arbitrary address, typically to the internal ‘secure’ network; check out our in-depth article on SSRF! SSRF’s inclusion was a long time coming – yet in 2017 they’ve listed it as one of the vulnerabilities to keep an eye on – as it is a direct workaround for firewalls and other techniques that try to cut off sensitive servers from the outside. Many recent high-profile breaches exploit SSRF vulnerabilities – the infamous Capital One breach from 2019 is a good example.
A11:2021, also called Next Steps, covers the issues that are impactful, but didn’t fit into the OWASP Top 10. These are Code Quality Issues, Denial of Service, and Memory Management Errors, and are all tightly connected to code vulnerabilities, either as causes or as consequences.

Since many of these categories are rather broad, some vulnerabilities can potentially belong to multiple of them. For instance, we could argue that SSRF was implicitly in the list already – since it’s a subclass of the ‘Confused Deputy’ weakness, which itself is a failure of access control. Similarly, Cross-Site Request Forgery (CSRF) and its more modern counterparts such as clickjacking can be considered either ‘confused deputy’ problems (and thus now belonging to A01), or session handling issues (and thus belonging to A07). For another example, OWASP Dependency Check is mentioned both in A06:2021 in the context of dealing with vulnerabilities in third-party components, and in A08:2021 in the context of protecting the software supply chain; which is of course OK.

Is it the Top 10, or the Top 193?

At first, the new Top 10 may look daunting to those of us who were familiar with the 2017 iteration. Many familiar entries are gone or have been replaced with entries that sound more generic. But underneath it all, the old vulnerabilities are still there… you may have to dig for them.

One major change with the list is a stronger connection to the Common Weakness Enumeration (CWE) database. Most of the categories now refer to multiple weaknesses (the only exceptions are A06 and A10). In fact, after removing the two self-referential CWE entries (namely, two CWEs in A06: CWE-937 OWASP Top 10 2013: Using Components with Known Vulnerabilities and CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities), we can see that the OWASP Top 10 2021 actually covers 193 distinct weaknesses.

Of course, CWE granularity is not uniform: a category can contain both broad CWE entries like CWE-2 Environment, as well as highly technology-specific ones such as CWE-1174 ASP.NET Misconfiguration: Improper Model Validation. Similarly, the number of CWEs is not necessarily proportional with severity. For instance, A01 contains three CWEs that all cover various aspects of path traversal (a comparatively small part of the category), while A06 – after removing the aforementioned self-references – contains only one CWE (CWE-1104 Use of Unmaintained Third Party Components) –that single entry however represents a very significant part of the system’s attack surface. All this still gives us a good sense of scope, and an important realization: each Top 10 tries to include more and more weaknesses and threats than those in the previous iterations.

What this means is that when we talk about the OWASP Top 10 2021, we are talking about 193 issues, not just 10. Of course, earlier Top 10s contained CWE references as well, but the scale is very different this time. In 2017, there was a total of 24 CWEs referenced in the top 10 – compared to that, 193 is a huge increase!

The wording of the new Top 10 helps clarify this shift in focus as well. While the Top 10’s full title is Top 10 Web Application Security Risks, this is the first iteration where the items on the Top 10 are explicitly called ‘categories’ instead of ‘entries’, ‘risks’, ‘issues’, or even ‘vulnerabilities’. There are only two clear exceptions: Injection (a longtime mainstay of the Top 10) and the new Server-Side Request Forgery or SSRF – which is a specific vulnerability that was chosen based on the community survey.

The new approach has understandably generated some apprehension from security experts. They claim that the new categories are much less specific and are generally moving towards broad concepts instead of concrete problems with code. This is generally harder to translate into direct instructions for developers. Daniel Miessler, an OWASP member and leader of the Top 10 IoT project, has noted in an analysis of the new Top 10 that the list doesn’t have a clear identity – many of the entries are broad categories, but individual vulnerabilities like SSRF are still being represented as well.

Another good analysis from John Carroll aka @yosignals (posted in the Top 10 Github repository) highlights that the new Top 10 deals much more with consequences rather than root causes. While it actually does deal with root causes through the individual CWEs, most people who look at the Top 10 will not look as deep. Both analyses point out that Insecure Design, in particular, is hard to grasp – it is such a high-level issue that it arguably encompasses everything else on the Top 10.

Right or wrong?

OWASP Top 10 is gradually becoming a “list of everything”, which can limit its direct usefulness to developers. The previous iterations always drew developers’ attention to certain issues that were the most common problems at the time. This “feature” was on one hand beneficial, as it always indicated the low hanging fruit to deal with for a start. On the other hand, this also carried the risk of comprehending the list as a kind of compliance schema, which Top 10 has never been: for many developers it was unfortunately THE journey through software security, and not just the starting point. And that was bad.

In a similar way, the vagueness of some of the categories in OWASP Top 10 2021 can be challenging for the security industry as well. It is obviously much harder to write a tool (or design a security evaluation methodology) that can detect insecure design than one that can test for XXE or Cross-site scripting. As a consequence of this, we expect to see that the Top Ten will fade as the main drive for businesses, as it was for a decade or so.

But we at Cydrill believe that this new approach to the Top 10 is definitely beneficial from an education standpoint. The new comprehensive categories now provide a better coverage of many important aspects of secure software development that the earlier iterations of the Top 10 did not emphasize to the appropriate extent. Better than ever before, we can use the list as a backbone of a thorough secure coding curriculum and teach developers how not to code.