Hurrah and hooray: the OWASP Top 10 Web Application Security Risks list has been updated for the first time since 2017. So what does this mean for you? How can you apply the new list to make sure your appsec practices are top notch? And what even is OWASP anyway?
First of all, what is OWASP?
OWASP is the “Open Web Application Security Project”, a non-profit organization with the goal of improving security of web applications. It has been running for the last 20 years and in that time has become synonymous with everything from tooling and documentation to standards.
Got it. So what is the OWASP Top 10?
The number of possible vulnerabilities an application could have can quickly become overwhelming. For many, especially those new to application security, this can turn into decision paralysis: which flaw or vulnerability should you fix first when there could be so many?
That’s where the OWASP Top 10 comes in. This list, which has been around since the far distant days of 2003, exists to help you simplify and prioritize. It lists out the top 10 most impactful vulnerabilities an organization should focus on when looking to improve the security of applications and reduce their overall risk. It has become the de-facto standard in application security, and is often referenced in security tooling as well as other materials, like penetration reports and training.
The list offers a valuable insight into where we as an industry are heading, as well as which areas we’re still struggling to resolve. After all, if the same thing is appearing in the lists over and over again, then there’s something wrong with our approach.
Now that a new list has been released, it’s a great time to step back and reflect on how far we have come – and how far we still have to go.
How can I use the OWASP Top 10?
As mentioned above, the OWASP Top 10 provides a starting point when triaging and prioritizing the vulnerabilities of applications.
It’s also used in many security-related materials and tools, creating a common language when dealing with or preventing vulnerabilities. The power of this common language is substantial, and we see its value in so many other security frameworks (Mitre ATT&CK and NIST’s NICE to name a few). Having a list that the entire industry recognizes helps consolidate and clarify the results from different tools, ensuring they make sense to everyone – especially to those with a lower level of security knowledge.
Finally, the OWASP Top 10 is a fantastic education and awareness tool – I often use it in my introduction to application security awareness talks. It’s such an easy way to communicate the most impactful and prevalent web app vulnerabilities to the whole team involved in the SDLC. It’s valuable for your developers so they can avoid introducing them in their code, your testers so they can watch out for them in their testing, and your operation teams so they can properly configure production and other critical environments.
This list has become so synonymous with application security that you will have a hard time talking about it without making any mention of the OWASP Top 10. So let’s get stuck into the nitty gritty of how the list has evolved since 2003.
2017 vs 2021
Much has changed in the world since the last Top 10 in 2017. Sadly, the same can’t be said for the OWASP Top 10.
A direct comparison between the two doesn’t paint a pretty picture. Every single item from 2017 is still in the current list, either directly or combined in a new category. Having said that, if we were to take the more optimistic view, the fact that these individual categories have now been grouped together could mean that they are less prevalent than before.
An intriguing term has been introduced in this version of the list that we haven’t seen before: “failures”.
To me, this represents a shift in the nature of the most prevalent vulnerabilities. In the past, many vulnerabilities were introduced via some type of logical or functional flaw, typically an issue with the code itself. Now, however, we’re seeing security baked into things such as frameworks and services. To me, the term “failures” recognizes this, and reframes the problem as either the failure to use, or the misuse of, security features and configurations. For example, in the Cryptographic Failures category, this would mean not using a strong cipher suite, and in the Software and Data Integrity Failures category, not enabling signature verification on package downloads.
This is also the first time we’ve seen “Insecure Design” appear in the list, notable simply because it relates to a missing (or flawed) step before development even begins. This is a really important step towards “shifting left”, as design is one of the elements that sits to the left of an application’s development lifecycle.
What can we learn from the evolution of the OWASP Top 10?
Let’s take a step back even further and look at all the previous lists in relation to one another:
One of the most obvious and significant things that has happened over the years is the Buffer Overflow category dropping off the 2007 list. Now, this didn’t fall off the list because it was no longer an issue; in fact, if you have a look at the 2021 CWE Top 25 Most Dangerous Software Weaknesses, you will see that it is still the #1 vulnerability. So did we solve buffer overflows in web-based applications? Sadly, no we didn’t – we simply moved to different technologies where these vulnerabilities are not possible.
The list also provides an insight into the evolution of the industry. Take, for instance, the introduction of Using Known Vulnerable Components in the 2013 list. This indicates a trend where developers started to leverage open source at scale, incorporating components such as libraries and frameworks into their applications rather than developing everything internally.
Unfortunately, as is often the case, new technologies and approaches can result in new areas of security weaknesses and flaws. Just a few weeks ago, for example, we saw that supply chain attacks have increased by 650% since 2020.
Alarmingly, if we review all eight lists side-by-side, we will see the following categories appearing in all of them (either as the same category or grouped into another category):
- Broken Access Control
- Broken Account and Session Management (now referred to as Identification and Authentication Failures)
- Injection
- Sensitive Data Exposure (now referred to as Cryptographic Failures)
- Security Misconfiguration
That means 18 years is still not long enough for us, as an industry, to remedy these flaws. With the exception of the Injection category, which is quite broad, the other four are business logic or misuse flaws.
And, if we compare the first list from 2003 with this year’s list, we can see that seven of the 10 items are still an issue in some shape or form.
Tackling “Failures”: The Human/Tech Hybrid Approach
All of this means we have to change our approach – and I think we are, albeit slowly. The best thing we can do now is to focus on empowering the people who build, test, and secure these applications.
One of the main reasons we keep seeing the same issues appear in the OWASP Top 10 is that people and technology don’t always work together effectively. Tech can go a long way towards removing vulnerabilities and risks (as in the case of Buffer Overflow), but it can also introduce new ones (as in the case of Using Known Vulnerable Components) – especially when it’s misused or misconfigured. The increase in categories relating to logic flaws and the misuse of features shows us that this is a growing issue.
Effective application security isn’t just about spotting traditional vulnerabilities; it’s also about knowing the impact of altering a framework’s security features or how to use security features via configuration. If we want to tackle these “failures”, we need to level up the knowledge, skills and judgment of the people behind the screens so they can make full use of the technology they have to hand.
Adopting a hybrid human/technology approach will put us in a powerful position to elevate application security and, hopefully, resolve some of the most impactful issues from the last two decades.
This is the philosophy behind Immersive Labs’ Application Security labs. They’re designed to be understood and used by everyone involved in the lifecycle of an application, from front-line developers to QA/testing, operations, product managers, and architects, so they can learn to identify, fix and prevent security vulnerabilities in applications. Once we’ve taken steps to empower the people behind the screens, I feel confident that we’ll start seeing less of the same thing in future OWASP Top 10 lists.
If you’d like to find out more about the latest OWASP Top 10 list, download our cheat sheet here.
Sean Wright
Principal Application Security Engineer,
Immersive Labs