What the OWASP Top 10 2021 categories mean for OWASP compliance

How the OWASP Top 10 has evolved

September 24th, 2021, marked the 20th anniversary of the Open Web Application Security Project. A non-profit organization founded at a time when web security was still in its infancy, the OWASP Foundation has been a major force in raising awareness of web application security through projects such as the OWASP Top 10. Since the first edition in 2003, this list of top ten application security risks has evolved to reflect industry trends, web technologies, and threat landscape – and this evolution is the key to understanding fundamental changes made in the 2021 edition.

Early editions of the OWASP Top 10 were, quite literally, about building awareness that web vulnerabilities exist and can be a cybersecurity risk, so the top ten categories were directly related to specific security vulnerabilities and types of application weaknesses (CWEs). As web applications became more technically advanced, more complex, and more deeply integrated into business processes, the OWASP list categories started to incorporate higher-level web application security risks. These included overarching design problems that are not directly testable and can manifest themselves in a variety of ways – a trend that has culminated in a separate Insecure Design category.

Category analysis: newcomers and reshuffles

The 2021 OWASP Top 10 combines vulnerability testing data from project contributors (8 categories) with community survey results (2 categories). Because aggregated data from vulnerability testing is inevitably historical, survey data was incorporated to identify current trends that might not yet be reflected in test results. Let’s go through the categories, see what has changed compared to the 2017 top 10 list, and analyze what the new ordering implies.

A01:2021-Broken Access Control

Up four places to take the #1 spot is Broken Access Control – a regular feature of the OWASP Top 10. This time, it covers 34 separate security issues that can all allow malicious actors to access data, resources, user accounts, or operations that shouldn’t be accessible to them. Example CWEs include various avenues of sensitive information exposure, direct data access via path traversal or forced browsing, missing or incorrect authorization, open redirects, and improper storage of sensitive data.

The rise of Broken Access Control to the top of the list corresponds directly to the massive rise in the number and scale of data breaches in recent years. With so much sensitive and valuable data now accessible through web applications and services, security controls for resource access must be an integral part of application design, development, and testing. For example, if an API is intended to provide read-only data access, but no access controls are in place to limit HTTP commands only to GET, attackers may be able to modify data using POST or other request types. You could also have a flawed implementation of access control using JSON Web Tokens (JWTs), where the tokens are used but don’t actually enforce access control.

A02:2021-Cryptographic Failures

This category was previously called Sensitive Data Exposure and is up one place since 2017. The renaming corresponds to OWASP’s general shift towards preferring root causes to symptoms in category names (since sensitive data exposure is one possible consequence of cryptographic failures). The category includes 29 weaknesses related to all aspects of data encryption, from using only secure and suitable algorithms to applying them in all the right places.

More generally, the word “cryptographic” in the category name serves as a clear reminder that encrypting all sensitive data in transit and at rest is no longer just a recommended practice – it is now an absolute must. An obvious example is applying HTTP Strict Transport Security (HSTS) to ensure that all traffic to and from a web application is encrypted to prevent data exposure and session hijacking attacks. A common security failure from this category is the use of weak hashing algorithms such as MD5 to store credentials or other sensitive information, as is using unsalted hashes – both vulnerable to brute-forcing by attackers with ever more computational power at their disposal.

A03:2021-Injection

In earlier editions, the most popular and dangerous injection attacks got their own categories, but in 2021, the Injection category has been consolidated to include everything that is technically an injection. Notably, apart from SQL injection, command injection, and other injection flaws, it now includes cross-site scripting (XSS), which has lost its own category and moved in with the rest (being essentially JavaScript injection into the victim’s browser).

Of the 33 weaknesses mapped to this category, most have “improper neutralization” in the name, pointing to the root cause of injection attacks: mixing user-controllable input (or more generally any untrusted data) with commands without making sure it is safe. While the list of specific injection weaknesses changes as web technologies evolve, doing proper validation, sanitization, and encoding is always a must, whether for NoSQL, JavaScript, LDAP, or any other technology. In fact, the best way to avoid injection vulnerabilities is to strictly separate code from data by using dedicated interfaces, parameterized queries, and similar constructs. Many frameworks use this approach by default, which might explain the lower rank of this category compared to previous editions.

A04:2021-Insecure Design

The biggest and most controversial addition to the top ten is Insecure Design – a catch-all category grouping weaknesses caused not by isolated mistakes but by a fundamentally flawed approach to software development. While shifting left to include security in development is vital, software security should start even before coding (and definitely before testing), with secure design patterns, secure reference architectures, and threat modeling. 

The top ten has traditionally focused on insecure implementations – the “how” of development. The new category is intended to move the focus away from the technicalities of implementation and start people asking: What are we trying to do here? Or better still: Why are we doing it this way in the first place? Among the 40 CWEs in the category, you will find business logic errors, insufficient restrictions, incorrect privilege assignment, and many other flaws that are not directly testable vulnerabilities. Addressing these as well as insecure implementations is crucial because (to quote the authors):

A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation.

A05:2021-Security Misconfiguration

Another perennial top ten member, security misconfigurations have climbed up one place since 2017. Notably, this category now includes XML External Entity (XXE) injection, which popped up as a short-lived separate category in the previous edition. The demotion of XXE vulnerabilities comes as no surprise, as these could only occur with permissive XML parsers with legacy DTD support, so using XML document processors from modern frameworks and libraries greatly reduces that attack vector. 

As web applications grow ever more complex and incorporate multiple components across a huge variety of technologies and environments, configuration errors are likely to remain a major security risk in the future. Typical vulnerabilities that fall into this category include insufficient system hardening, missing or incorrect security headers, and running software with insecure default settings (including default credentials, accounts, and privileges).

A06:2021-Vulnerable and Outdated Components

It’s no secret that once deployed, JavaScript libraries are rarely updated, and the same is true of other components, especially open-source. With web applications commonly relying on dozens of external dependencies, vulnerable libraries and frameworks can be a major source of security vulnerabilities, as can outdated server-side technologies. Up three places from the previous edition and slightly renamed from Using Components with Known Vulnerabilities, this category isn’t going away any time soon.

Vulnerable and outdated components are one aspect of software supply chain security – a very hot topic in recent months in the wake of the SolarWinds hack. While attackers maliciously infiltrating the software supply chain would be compromising software integrity (see separate category below), having unpatched components in your supply chain can be just as dangerous. In fact, you could argue it’s even worse because then you’re exposed not to one determined actor but to an entire web of cyberthreats.

A07:2021-Identification and Authentication Failures

This category was previously #1 under the name of Broken Authentication. It includes common sins such as bad password management, lack of rate-limiting to prevent credential stuffing, insecure session management, and using authentication mechanisms that can be bypassed. While the OWASP data suggests a lower incidence rate, which presumably explains the lower rank in this edition, authentication-related attacks can be extremely dangerous when automated to extract credentials on a massive scale. According to the Verizon DBIR for 2021, 61% of all data breaches involved stolen credentials, so this category is here to stay.

When exploited directly, vulnerabilities related to authentication can have serious consequences, including user session hijacking, user identity spoofing, and account takeover. Multi-factor authentication combined with secure password policies and rate-limiting can help to mitigate many of these threats. Authentication mechanisms also need to be designed and implemented correctly to ensure they cannot be bypassed.

A08:2021-Software and Data Integrity Failures

New in the 2021 edition is another high-level category, this time related to integrity failures – in other words, blindly trusting that nobody has tampered with your software and data. The SolarWinds attack is the best-known case of a failure to ensure software integrity, but the more recent (and more damaging) Kaseya hack falls into the same category. This category now encompasses insecure deserialization, where data from untrusted sources (or trusted data stored after serialization) is deserialized without verification, which opens the way to remote code execution and other high-severity attacks.

Similar to using vulnerable or outdated components, this category reflects the growing dependence on third-party software and data sources. Compromising an upstream component used in thousands of systems or devices allows cybercriminals to multiply a single attack on a massive scale by riding the software supply chain. Examples range from unpatched firmware in home routers and other IoT devices to malicious code in network management software. Protecting against software and data integrity failures requires full visibility into the entire supply chain and putting measures in place to verify and test all software components across the whole development lifecycle, including CI/CD pipelines.

A09:2021-Security Logging and Monitoring Failures

Up one place from the previous edition and slightly renamed from Insufficient Logging & Monitoring, this is another OWASP Top 10 regular, corresponding to detection and response rather than vulnerability testing. To detect a web-based data breach, you need to have logs that you can check and monitor for suspicious activity. Otherwise, you have no way of telling if you have a breach, other than someone noticing something by accident – which is how all too many breaches are discovered. While we tend to think of an attack or breach as a sudden and short-lived event, system and data compromises often go on for months and remain undetected for years.

This category of failures can have direct regulatory consequences, especially for reportable breaches that involve personal information or other sensitive data. For example, if attackers extract credit card information or medical records from a company system and the breach is only discovered by security experts when the data appears for sale on the dark web, the company could face huge fines for not reporting it as soon as possible. As more and more of the world’s data resides in cloud-based systems, the importance of logging and monitoring can only increase.

A10:2021-Server-Side Request Forgery

Even though it has received its own category for the first time, server-side request forgery (SSRF) is a well-known class of vulnerabilities. SSRF attacks rely on tricking a web server into blindly navigating to a URL supplied by the attacker in order to execute a malicious request that seems to originate from that server. The only single-vulnerability category in this year’s top ten, SSRF was an entry from the OWASP community survey.

The growing prevalence and impact of SSRF attacks is another consequence of the increasing complexity of modern web applications. To integrate dozens of services and data sources, applications now exchange and fetch URLs as a matter of course, which may put them at risk of SSRF. When exploited in complex cloud-based architectures that often include business-critical systems and services, server-side request forgery vulnerabilities can pose a major risk.

The new face of OWASP Top 10 compliance

As noted in an earlier post, the OWASP Top 10 for 2021 has evolved away from being a list of vulnerabilities and towards being a list of security controls that must be considered for any modern web application. While many vulnerability scanners (Invicti included) test for OWASP vulnerabilities, the top ten was never intended as a vulnerability checklist or security standard because many aspects of security are not directly testable. The new edition states this upfront:

Tools cannot comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks, with reference to A04:2021-Insecure Design. OWASP discourages any claims of full coverage of the OWASP Top 10, because it’s simply untrue.

While we’ve written about this in the past, it’s worth restating that a vulnerability scanner can never test for all weaknesses listed in the top ten because that’s not its job. However, it can (and should) find all web application vulnerabilities from the list that are technically detectable using dynamic testing. As an industry-leading DAST solution, Invicti will detect and often automatically confirm OWASP vulnerabilities such as various types of injection, cross-site scripting (including DOM-based XSS), SSRF, missing HTTP security headers, and dozens of others. Crucially, it can also deliver accurate and actionable vulnerability reports directly to the developers’ issue tracker to help with remediation and foster secure coding practices.

OWASP says shift left and look at the big picture

As the industry’s most powerful awareness document for web application security, the new top ten semi-officially sanctions many recent security trends. The current choice of categories reinforces the message that security is a cross-cutting concern that must be considered at all stages of the application lifecycle, from design and coding through deployment and operations. This includes expanding traditional security testing to start already during development (popularly called shifting left), ensuring the security of all code that goes into production (not just your own), and thinking about security even before coding starts. In short, web application security needs to zoom out from merely looking for security flaws in the source code or running application and expand to a much bigger picture.

This reflects what we’ve been saying for years: that effective web application security must be an integral and efficient part of the SDLC. For our part as a modern DAST vendor, we can help by integrating into your existing development pipeline while also allowing accurate vulnerability testing at multiple stages of the application lifecycle. That way, an advanced DAST solution such as Invicti can help you both with shifting left and getting full visibility into your AppSec posture.