The new OWASP Top 10 is not what you think

A brief history of the OWASP Top 10

The Open Web Application Security Project (OWASP) needs no introduction to cybersecurity readers. Soon celebrating its 20th anniversary and counting Invicti among its many corporate supporters, this non-profit project has been promoting web application security awareness for as long as web applications have existed.

The Top 10 list of web application security risks is one of OWASP’s flagship projects. From the first edition in 2003, the OWASP Top 10 has been the AppSec yardstick for software developers and tool vendors – but this year, things are a bit different. OWASP itself has always positioned the Top 10 as an awareness document that highlights security risks to consider and prevent, not as a list of specific issues to find and fix. The 2021 iteration emphasizes this even more strongly, with new categories that deliberately move the focus away from low-level vulnerabilities and towards building security deeply into every level of application development.

Zooming out for a wider security picture

As with previous editions, the new OWASP Top 10 was built by organizing security weaknesses (CWEs) into ten categories. We will do a deep dive into the 2021 categories in an upcoming blog post, but here is a quick rundown of the new categories along with changes compared to the previous edition:

• A01:2021-Broken Access Control (↑ 4, covers 34 separate CWEs)
• A02:2021-Cryptographic Failures (↑ 1, previously Sensitive Data Exposure)
• A03:2021-Injection (↓ 3, now includes XSS)
• A04:2021-Insecure Design (new)
• A05:2021-Security Misconfiguration (↑ 1, now includes XXE)
• A06:2021-Vulnerable and Outdated Components (↑ 3, previously Using Components with Known Vulnerabilities)
• A07:2021-Identification and Authentication Failures (↓ 5, previously Broken Authentication)
• A08:2021-Software and Data Integrity Failures (new, now includes Insecure Deserialization)
• A09:2021-Security Logging and Monitoring Failures (↑ 1, previously Insufficient Logging & Monitoring)
• A10:2021-Server-Side Request Forgery (new, a.k.a. SSRF)

Note that these are based on the latest draft proposal, so some details may still change in the coming weeks.

While there has been a lot of reshuffling and renaming that we will examine in a separate post, the biggest change introduced by the authors is to make most of the risk categories more generic. Reading into the details and methodology, this was done deliberately to encompass more CWEs than in previous editions and also talk more about root causes and less about symptoms.

Especially in the first few editions, the Top 10 was very much focused on specific vulnerabilities and as such was commonly (mis)used as a security checklist. While convenient, this gave the false impression that web application security was only about finding and eliminating vulnerabilities in the final application. The new classification brings a higher-level view of application security, which fits in perfectly with current industry efforts to shift left and incorporate security into development.

Shifting left with OWASP

The addition of the Insecure Design category sends a clear message that shifting left and considering security requirements from the earliest stages of development is now an OWASP-sanctioned AppSec best practice. The new category is home to several dozen CWEs related to insecure coding and application design, from insecure storage and processing of sensitive data to business logic errors that could be abused to access privileged accounts or operations. Addressing and preventing such issues takes far more than reacting to vulnerabilities. Quoting from the draft:

Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. 

Secure coding practices are as important as the actual testing, which makes sense on many levels. For example, repeated failures to sanitize user inputs will lead to a never-ending stream of injection vulnerabilities, from cross-site scripting (XSS) to SQL injection and more. Even if specific issues are found in testing and fixed, many more will appear in the future unless the root cause is addressed through developer education and the right tools and processes. It is also far cheaper to find and fix security bugs early than at later stages.

Crucially, to be useful and efficient in practice, all this needs to be done systematically:

Secure design requires a secure development lifecycle, some form of secure design pattern or paved road component library or tooling, and threat modeling.

This is where the importance of modern AppSec solutions such as Invicti really comes to the fore. While there are many ways to build a secure software development lifecycle (SDLC), integrating accurate dynamic application security testing (DAST) is a particularly efficient approach that allows you to run automated vulnerability checks at multiple stages of the development pipeline. Developers can get rapid, reliable, and actionable feedback on security issues directly into their issue tracker, which helps them both improve the current security posture and incorporate secure coding principles into their future work.

Using the new OWASP Top 10 in practice

The Top 10 was never intended as a security testing checklist, and the 2021 edition really hammers this point home. It is now squarely an awareness document that calls out the 10 main reasons why web applications may be vulnerable to attacks. Created using both test data and industry surveys, the Top 10 also incorporates current trends such as shifting left (under Insecure Design) and software supply chain security (under Vulnerable and Outdated Components).

While arguably less useful to security practitioners than earlier editions, the new OWASP Top 10 takes a wider view of modern AppSec, emphasizing that it’s no longer enough to find and fix specific vulnerabilities. Considering the scale, complexity, and speed of web application development, especially at an enterprise level, the only way to get a grip on security is to embed it into every stage of software design, development, testing, and operations – and this is exactly what OWASP is telling us now.