Every three to four years, OWASP releases a new version of arguably its most famous project, the “OWASP Top Ten”. Originally started in 2003, this list serves as an awareness document to highlight the 10 most prevalent issues for web applications. The newest release marks the eighth iteration and has once again undergone a few key changes.

In this article, we will first take a look back at the project’s evolution over the last 22 years and highlight a few overarching shifts and developments. We will then take a closer look at the newest version and what the changes mean specifically for penetration tests.

Before we start discussing individual topics, I want to introduce a small tool to help visualize the evolution of the Top 10 over the years:

In the default configuration, it will show the categories for each year and how they moved over time. If you click on a category, it will highlight its entire history and its changes.

At the top, you will also find an option to color the categories based on a selected attribute. For now, there are two options: You can either color all categories by their status, indicating if they are still in the newest version of the Top 10, or you can color them based on their vulnerability class. This class is not something that is taken directly from OWASP. Instead, this is my best attempt at trying to put the categories into various boxes and grouping them into four vulnerability classes. As such, it is subjective and open for discussion, and you might disagree with some or all of the categorization. However, I think it does have a purpose for discussing the overall shifts, as we will see.

Let’s take a look at the overarching trends that have shaped the lists over the years.

Broadening

The biggest trend that can be observed is that the categories in the list have gotten broader and more encompassing over the years. In all of its history, 12 categories have been added to the list, while only 7 have been removed. This is especially true in recent years, as the last time a category was removed was with the 2017 update. Still, 2021 and 2025 introduced 2 and 1 new categories respectively, which means that categories had to be merged to make room for the newcomers.

A good example is the “Injection” category. Throughout most of the history of the Top 10, this used to be two categories, “Injection” and “XSS”. In the 2021 update, they were merged into a single one, and the definition now includes all kinds of injection-related vulnerabilities, not just XSS.

A very similar story can be observed for the “Broken Access Control” category. For a long time, this category used to be split over two separate issues, “Insecure Direct Object References (IDOR)” and “Failure to Restrict URL Access”, before being merged into the more generic category. If we look at the CWEs assigned to this category in the 2021 and 2025 versions, even “Cross-Site Request Forgery (CSRF)” is now considered to be part of it. However, this has been omitted from the graph, as this merge is not mentioned as an official one in the 2017 update. As the latest addition to the “Broken Access Control” category, “Server-Side Request Forgery (SSRF)” (which just had its debut four years ago) was merged into this category as well.

In summary, this means that categories are moving away from narrowly defined specific vulnerabilities towards wider, more abstract classes of issues. Compared to earlier years, when categories often referred to very specific vulnerabilities, we now have very broad catch-all terms that capture a lot of specific issues.

Shift-Left

The industry overall has been “shifting left” for quite some time now, and it makes sense that the Top 10 follows this trend. Once again, the classification into the vulnerability classes is subjective, but sufficient to witness an overarching trend.

In the early years, the list was always topped by technical vulnerabilities. “Injection” (and its sibling “XSS”) held the A01 spot for most of the project’s lifetime. In the last two versions, it has been surpassed by “Broken Access Control” and has been relegated to spots 3 and 5, respectively.

It becomes even clearer if we focus on “Security Misconfiguration”. Starting at the very bottom of the first list as A10, this category was even removed in 2007 before it was reintroduced in 2010. It then held on to the middle of the pack, and in the newest iteration has been promoted to A02.

But probably the biggest example of the shift-left trend is the addition of “Insecure Design” in 2021. This was very surprising at the time, since such a control was previously never part of the Top 10 and is more “left” than any other category has been.

In summary, we can see that the earlier years were dominated by technical vulnerabilities and logic issues, with configuration problems and design issues only appearing towards the bottom of the list. Nowadays, however, configuration and design make up half of the list.

The shift left is, of course, due to a couple of very good reasons. Almost no applications nowadays are developed entirely from scratch. Frameworks are often used, especially for key parts like persistent data storage or output rendering. This leads to a situation where a vulnerability like SQL Injection or Cross-Site Scripting almost requires additional effort from the developers to introduce.

Quo Vadis

Where do these changes and trends lead us to? Initially the Top 10 was meant to be a list of “vulnerabilities that require immediate remediation”. The target audience were developers, their managers, but also security professionals who “should include these items in their reviews”.

However, as we have seen, over the years the categories have only gotten broader and less concrete, with half of all categories now covering over 30 CWEs.

Nowadays, OWASP makes it very clear that the Top 10 project is primarily an Awareness document. It is only considered to be the “bare minimum” for coding standards and penetration testing alike. It also no longer makes any claims of being a “testable” standard. For these use cases, OWASP instead positions and recommends the Application Security Verification Standard (ASVS).

As a result, asking for a penetration test to be done “according to the Top 10” is as ill-advised as offering such a service. The list is not meant to be a testable standard, and focusing on only the Top 10 omits many vulnerabilities that could be used to attack an application. This does not mean, of course, that penetration testers cannot benefit from the Top 10, as we will discuss now.

Let’s go over the 10 categories and see how they apply to penetration testing. “Penetration Testing” in this context means an external third party who has access to the application, but not necessarily access to the source code and/or administrative access to the backend. As such, black-box testing will be the default modus operandi.

Broken Access Control

This category remains at the very top of the list, and deservedly so. We have already discussed the reasons why vulnerabilities in the Injection category are on the decline, but Access Control remains a central part of applications, often requiring custom logic and careful implementation. In addition, modern web applications are less and less implemented in a single, monolithic way, but rather utilize APIs, microservices, and external components. With so many moving parts, it’s easy to misconfigure a component or have incorrect expectations about who is responsible for performing the access control in the first place.

This category contains a wide range of specific vulnerabilities, but to test most of them, a solid understanding of the intended behavior of the application is crucial. As an external tester, it’s often difficult to understand who should be able to access which data or perform which actions. Therefore, access to documentation and interviews with someone familiar with the application are a necessity to ensure proper testing.

Most vulnerabilities in this category can be identified through tampering with the inputs, be it the URL, parameters within them, or data sent inside the requests.

Security Misconfiguration

This category contains all issues that could have been prevented with configuration changes to the application or the software stack used. Together with the next category, it has gained the most spots in the OWASP Top 10’s evolution.

Some security misconfigurations are easy to identify from the outside and should be part of any penetration test. These are issues like incorrect security headers or cookie flags, unnecessary open ports, or default pages.

Others, however, require either access to the source code, administrative access to the backend, or at least to properly documented settings. For example, it would be very difficult, if not impossible, to identify if secrets are properly handled on the backend or if they are hardcoded into the source code.

Software Supply Chain Failures

Previously called “Vulnerable and Outdated Components”, this old name captures the essence of the category quite well. The intention of the renaming is now to include all problems that arise due to not managing the entire supply chain.

From the perspective of a penetration tester, the widened definition does not result in a larger testable scope. Checking for outdated libraries and known CVEs will continue to be part of any good checklist. However, testing the DevOps side of this category is typically not going to be part of a standard web app penetration test.

Cryptographic Failures

This category includes everything that has to do with encryption and has been in the Top 10 every year of its existence. These failures cover data at rest, but also all data in transit.

For penetration testers, this is very similar to “Security Misconfiguration”: some aspects can be tested easily from an external perspective, while others cannot. For example, an insecure TLS configuration can be identified with the same ease as unencrypted protocols, but testers will likely not be able to determine how data is handled and stored without backend access or documentation.

Injection

Injection covers every issue that arises due to user-controlled data being handled in an insecure way. This includes Cross-Site Scripting (XSS) and its less impactful cousin, HTML Injection, SQL and NoSQL Injection, but also less common injections for technologies such as LDAP or the Spring Expression Language (SpEL).

After “Broken Access Control”, this is the second category where penetration testers can identify many issues from an external perspective. Most of these issues can be discovered “blind”, though having access to the source code will increase coverage and speed up detection times. Understanding the underlying software stack is also going to reduce the number of test cases significantly, as the injections can then be tailored to the environment.

Insecure Design

This category captures all vulnerabilities that exist due to choices in the design of the application, rather than due to implementation or configuration mistakes. As such, it incorporates issues that were introduced long before the first line of code was written. Eventually, the outcomes and effects of these decisions can and will manifest in vulnerabilities that can be identified during a penetration test. But from a purely external perspective, it is often not clear if the root cause was a design issue or an implementation error.

This also means that a penetration test happens too late in the software development lifecycle (SDLC) to identify and prevent issues in this category. Instead of only asking for a penetration test shortly before an application is supposed to go live, application owners should request support as early in the lifecycle as possible. This way, security input can already be given through Threat Modeling, Architecture Reviews, or similar types of assessments.

Authentication Failures

Where the first category on the list was all about authorization (“What can you access?”), this one is purely about authentication (“Who are you?”). Weak password policies, susceptibility to brute-force attacks and default accounts all fall in this category.

As a penetration tester, most of these issues are easy to identify, especially if self-registration for accounts is possible. Some vulnerabilities in more complex authentication schemes, like OAuth or mTLS, require specialized knowledge or tools.

Software or Data Integrity Failures

This category contains all the issues that arise because the integrity of an artifact (either software or data) has not been correctly validated.

For penetration testers, the main case of vulnerabilities in this category is insecure deserialization. It can lead to diverse consequences, ranging from unintended access all the way to unauthorized code execution. From this perspective, there can be some overlaps with the Injection category.

Logging & Alerting Failures

Whether the application behaves in the intended way or not, can often be monitored by correctly implemented logging and alerting. In fact, not just normal application behavior, but also suspicious behavior that indicates an attack, like a sudden spike of invalid login attempts or the outflow of an unusually large amount of data to a single endpoint can be detected or at the very least analyzed after the fact if these systems are working properly.

It is very important for any organization to take care of proper logging and alerting. For a penetration test, however, this is typically out of scope. Assessments are often performed in a test environment, where logging might not be set up the same way as in production. In addition, administrative access to the backend (for example to the server logs or a SIEM) is typically needed. Lastly, verifying the effectiveness of logging is generally something that requires dedicated assessments.

Mishandling of Exceptional Conditions

The last category on the list is a new one, although it does incorporate some elements that used to be part of the lists in previous years, like Buffer Overflows. It combines all situations where the application isn’t properly handling an edge case. This can be user input that was not correctly handled, like a negative number in an input field only expecting positive values; improper error handling, where the user sees the entire error message including stack traces or internal information like an SQL statement; or the failure of an application to respond to environmental conditions like insufficient storage space.

For a penetration tester, issues in this category will often be identified almost by accident while testing for other vulnerabilities. Rarely will someone send an input to the application with the sole intention of analyzing the resulting error handling, but instead, some test initially intended to test something different will suddenly reveal an improper response from the application.

All in all, we have seen that only a select few categories are really at the core of what a penetration tester will typically look at. The “Broken Access Control”, “Injection” and “Authentication Failures” categories are all highly relevant to regular penetration tests. On the other hand, “Insecure Design” and “Logging & Alerting Failures” are outside of default scopes and will not be covered.

The following table is an overview of which assessment types are best suited to identify issues in the Top 10 categories. “✅” means that there is a high chance of finding all or most issues, “➖“ means that some issues can be identified, while others are unlikely to be uncovered, and “❌” means that issues in this category are very unlikely or impossible to be identified.

	Traditional Penetration Test	Penetration Test with Source Code Access	Configuration Review	SAST and Software Composition Analysis (SCA)	Threat Modeling
Broken Access Control	✅	✅	❌	➖	➖
Security Misconfiguration	➖	✅	➖	➖	❌
Software Supply Chain Failures	➖	➖	❌	✅	❌
Cryptographic Failures	➖	✅	➖	➖	❌
Injection	✅	✅	❌	➖	❌
Insecure Design	❌	➖	❌	➖	✅
Authentication Failures	✅	✅	➖	➖	❌
Software or Data Integrity Failures	➖	✅	❌	✅	❌
Logging & Alerting Failures	❌	➖	➖	➖	➖
Mishandling of Exceptional Conditions	➖	✅	❌	✅	❌

The previously mentioned ASVS covers all the areas of the Top 10 that are relevant for penetration tests, but also covers more areas that are not (anymore) part of the Top 10. Due to its different focus, it also provides very clear, testable requirements compared to broad categories of vulnerabilities. Because of this, application assessments at NVISO are based on the ASVS.

Nevertheless, the Top 10 list will continue to serve in the way it is intended to be used: to increase awareness about all aspects of the software lifecycle.