Security threats on the web: The biggest risks according to OWASP Top Ten 2021

The Open Web Application Security Project (OWASP) pursues the mission to improve the security of (web-based) software. It organizes meetings and events, publishes numerous documentation and checklists on various aspects of web security, and also has software products under its aegis, including the well-known security scanner OWASP Zed Attack Proxy (ZED).

The best-known sub-project of the OWASP is a list of the greatest security risks for web applications that has been published more or less regularly since 2003: the OWASP Top Ten, which appeared for the first time in 2003 and the second edition in 2004. After that, OWASP switched to a three-year cycle: 2007, 2010 and 2013.

But this could not be maintained: The list planned for 2016 was under a bad star, was delayed, had a great need for internal discussion and ultimately accumulated in a half-baked release candidate in 2017. In comparison, the final list brought significant changes in some places and appeared a few months later in the same year. heise Developer summarized the background in more detail at the time.

Everything should be different in 2020, but it wasn’t just the pandemic that thwarted the plans. Who knows how long it would have taken to get the final list if it hadn’t been for the twentieth anniversary of OWASP on 9.9.2021. The anniversary evidently generated enough suffering to publish a preliminary version of the new top ten on September 8th, 2021. Despite some discussions, including in the project’s official GitHub repository, project manager Andrew van der Stock presented the new list punctually at the OWASP’s anniversary conference on September 24th, 2021:


List entry


Broken Access Control


Cryptographic Failures




Insecure design


Security misconfiguration


Vulnerable and Outdated Components


Identification and Authentication Failures


Software and data integrity failures


Security logging and monitoring failures


Server-side request forgery

Compared to previous editions of the top ten list, the team – accompanied by a project-specific homepage that was only inconspicuously linked to the OWASP site – gave a little more insight into the creation of the list elements and their order, although the basic approach was similar to in the previous editions. First, the organization collected anonymized data from security audits of web applications. The basis was the CWE project (Common Weakness Enumeration), which enumerates (enumerates) categories for security gaps in applications. The voluntary data donations for the OWASP Top Ten consisted essentially of CWEs and information about how often they were found. Figure 1 shows an excerpt from the merged data from the 2017 list.

Parts of the data collected for the OWASP Top Ten 2017 (Fig. 1)

The next step was to group CWEs sensibly in categories and then to put them in an order. This means that the top ten is 80 percent complete, with eight of the ten available positions. In order to be able to pick up on trends and observations from practice at an early stage, which may not (yet) be reflected in the bare figures, a community survey was carried out at the same time as to which CWEs would also have deserved a place. This results in the two missing list elements.

While this approach is well-documented, the potentially arbitrary grouping of CWEs and the integration of the survey results make it debatable. First and foremost: Are there items that are completely incorrectly placed on the list or are even completely missing? In the following remarks on the ten items on the current list, the author of this article dares to make a subjective judgment at one point or another.

According to the OWASP Top Ten 2021, the greatest risk is defective access control. The top point was represented in the previous list at number 5 and this time made the leap up. A total of 34 CWEs that matched the list entry contributed.

Basically, this point is about a lack of access protection, which can, however, occur in different forms: bypassing an existing access protection by changing URL parameters, missing authorization for other HTTP verbs than the intended, unsecured endpoints or files as well as replay attacks with JSON Web Tokens (JWT) – the list is long. As always, it is important to always check the entries and to ensure the appropriate authorization of the client at all times.

It may come as a surprise that Cross-Site Request Forgery (CSRF) has recently found a new home under this roof. Prior to 2017, the attack had its own spot in the top 10, and it narrowly missed the 2017 edition. At that time, based on his own findings in the context of audits and code analyzes, the author was of the opinion that he should have belonged in the top ten. In the meantime, the attack is probably no longer worth considering. In addition to well-functioning anti-CSRF measures, some of which are also active by default, in various web frameworks, SameSite cookies significantly limit the attack surface. A major renaissance of the attack cannot currently be assumed.

The somewhat terrifying term of cryptographic failure garners a respectable 29 CWEs under its direction. Many of the points listed, such as the use of insecure algorithms, are hardly relevant when using a reasonably modern stack. No contemporary framework still uses MD5 or SHA1 to hash a password – hopefully at least. On the framework side, developers in particular can have password hashing done automatically according to best practices (e.g. with ASP.NET Core) or fall back on an easy-to-use but secure API (e.g. with PHP).

In the OWASP Top Ten of 2017, the item was called “Sensitive Data Exposure”. At that time the main problem was probably not using encryption, especially on the transport route. Since most web browsers are now bullying sites without HTTPS (see Fig. 2), a further decline can be expected. The use of HTTPS also eliminates some, if not all, edges of session hijacking. The enforcement of HTTPS can be made even more stringent with HTTP Strict Transport Security (HSTS); the “secure” flag for cookies prevents them from being transported over unsecured communication channels.

No HTTPS, no love from the browser (Fig. 2)

A point of criticism that is often raised against the 2017 edition of the OWASP Top Ten – also by the author of this article – is Injection’s top position. This primarily refers to SQL injection, an attack against which it is easy to defend: Parameterized queries or prepared statements work with placeholders in SQL queries that clearly define what a date is and what a command. There is no reason (or excuse) for loosely concatenating strings. When using an object-relational mapper such as Hibernate, Entity Framework or Doctrine, the code is one step further away from potentially vulnerable SQL, as the work is carried out almost exclusively via an API, which makes SQL injection almost impossible.

The OWASP has always defended the top ranking of (SQL) Injection, especially in comparison with Cross-Site Scripting (XSS). This attack, which involves the smuggling of defective JavaScript code or HTML markup, has significantly higher values ​​in terms of absolute numbers than the database attack, but only ranked 7th in the OWASP Top Ten 2017 The appearance of an XSS leads to dozens of other XSS finds and thus falsifies the statistics.

This article comes from the new iX Developer special issue “Developing Safe Software”. On 156 pages it covers topics such as web application security, code analysis methods and cloud security. The focus on DevSecOps shows methods, tools and maturity models.

For specific programming languages, one article aims to help track down and avoid memory errors in C ++, and another shows the security concepts of Rust. Those who develop with Java will find an overview of the changes to the security from Java 11 to Java 17.

The subject area of ​​cryptography goes from the basics to the pitfalls when integrating cryptographic procedures in your own applications to the outlook on post-quantum cryptography.

The magazine is now available in the heise shop as a PDF for 12.99 euros. The printed version can be pre-ordered for 14.90 euros. A bundle of printed output plus PDF is also available.

Four years later it looks a little different. Injection has dropped to 3rd place. The apparently less relevant XSS is now part of the category – the smuggling of JavaScript is also technically an injection. Subjectively, that sounds like a good compromise. OWASP saved face (Injection still in the top 3), but the influence of XSS is clear. Without the addition of XSS, Injection would have slipped to the bottom of the top 10 according to the live presentation of the 2021 list.

However, this merger is not without criticism. The defense against XSS has many more facets than the protection against SQL injection. In addition to proper output escaping – depending on the context, since special character invalidation works differently within HTML than within JavaScript – defense-in-depth mechanisms such as Content Security Policy (CSP) help to put an end to malicious JavaScript and HTML markup . It is to be hoped that the risk of “injection” will continue to lose ground in the future.

The “unsafe design” category is a new addition. The intention is clear: important security concepts such as threat modeling and the use of reference architectures are underrepresented in many web applications. Security doesn’t start with writing code. The decision causes discussion – as do many general places in the OWASP Top Ten, especially when they are new.

Compared to other points on the list, only limited comprehensible actions can be derived. The OWASP Top Ten is a list of risks, not attacks, but most of the other items relate to attacks better. Since a safe design is important, its placement on the list is entirely justified.

To home page

Previous post On the way to autonomous driving: simulation-based testing with V2X communication
Next post Vue.js 3.2: Save Code in Single File Components