What You Think You Know about the OWASP Top 10 May Be Wrong

The Open Web Application Security Project (OWASP) is an open community dedicated to the mission of enabling companies to develop, purchase and maintain applications and APIs that can be trusted.  Since 2003, OWASP has been releasing a list of the 10 most prevalent application security risks every few years.

Unfortunately, using the OWASP as an industry standard leads many to misuse and misunderstand what OWASP does and doesn’t do. Let me explain.

Vulnerabilities vs. Risks

The purpose of the OWASP Top 10 is to build awareness of the most common exploits that hackers use to infiltrate and compromise data within web-based applications. As a result, it has become an unofficial industry standard that guides and directs the security approach of many companies today and serves as a staple for many vulnerability testing product-scoring mechanisms.

Even though it is used in security product scoring, the OWASP Top 10 is a list of the most critical security risks, not a classification system for vulnerabilities. A good illustration here is the XSS risk (A-7 in OWASP 2017). It can be exploited through different vulnerabilities, not only through Cross-Site Scripting (XSS) vulnerabilities but also through vulnerabilities of Response Splitting type (aka CRLF-injection) and many others. The fact that OWASP uses the same names for the risks as common categories of the vulnerabilities is a source of some confusion.

Is there a better alternative vulnerability classification system? Unfortunately, there isn’t a system that is both comprehensive and universally accepted by the industry. The most promising attempt at a classification and assessment system is the CWE (Common Weakness Enumeration), but it is still incomplete and complicated. CWE is focused strictly on web applications and is designed to classify a variety of software errors, including security issues. Another good attempt is WASC, designed to classify threats. Even though it is completely outdated (2010), it is still a useful tool because of its simplicity.

The vulnerability types and classes that exist now are no more than tags. Comprehensive classification and ontology of the security issues elude us still. The lack of a good classification system is one of the reasons the attackers are still quite successful despite the best efforts by the security industry.

Mapping Risk Overlaps

Not only is there confusion between the risks and vulnerabilities, but the risks themselves have significant overlaps, as demonstrated by the diagram below.

For example, it’s easy to see that A6 (Security Misconfiguration) is a superclass of everything. It is pretty obvious once you realize that every time any other risk is realized, the A6 risk is realized as well. This means that all the risks from A1 to A5 and from A7 to A10 are also covered by A6 Security Misconfigurations. We can also claim this outer zone of A6 and all the other OWASP Top 10 risks as “Non-OWASP Top 10 Security Misconfiguration issues” that should be covered by security process.

Secondly, we assert that all the issues have some overlaps with A9 (Known Issues). This is due to the fact that any issue that realizes any OWASP Top 10 risk can be known and will be known after some time. This outer zone of A9 and all the other OWASP Top 10 risks can be named as “Non-OWASP Top 10 Known issues,” and indicate what should be covered by patch management.

Authentication (A2) and authorization (A5 aka access control) intersect each other and A3 (Sensitive Data Exposure), as described in detail later in this article.

Because XML is a data serialization format, A4 (XXE) is completely included inside A8 (Insecure Data Serialization).

All the other classes have no intersections, except A6 and A9, which I refer to as “higher and lower OWASP Top 10 orbits.”

In-Depth Look at the OWASP Top 10

Let’s look at all the Top 10 points in more detail.

A1. Injections

This precisely means server-side injection issues. Technically, we can claim XSS as HTML and JavaScript injections. But at this point, authors mention only server-side protocols such as SQL, NoSQL (document/object-based, key-value, graphs, etc.), LDAP, Bash (aka OS commands injections), etc. The funny thing is that we also can also, in theory, claim all the authentication bugs as injections in some authentication protocol. But this is excluded here.

A2. Broken Authentication

Mainly this is about session and password management. It’s a little strange to mix credential stuffing attacks, session ID disclosure in URLs and storing unhashed passwords in a database into one risk, but OK.

A3. Sensitive Data Exposure

In the official paper, only cryptographic cases are covered, such as unhashed passwords (yes, once again, we have already counted these as A2), plain/text transport protocols, mistakes of implementation of encryption protocols (such as CA, CNAME, CRL/OCSP checks), etc. Now, you may ask, “Would it not it be better to call these encryption errors?” No—because technically your stack traces and application errors disclosed worldwide are also subject to this risk. The same risk!


XML External Entities or XXE is a new issue in the 2017 Top 10 list. This is the only new issue of the set that was introduced based on direct data evidence from the security issues database. As we mentioned earlier, complex data structures and metadata are prevalent. In addition to XML-based API protocols such as WSDL, SOAP and others, XML is the language of choice for metadata of everything from movies to Docker containers. Moreover, within the single applications, several daisy-chained XML interpreters may exist, depending on which tier of the application processes which part of the data. This potential ability to inject an external entity at various points in the application stack via an XML interpreter is what makes XXE so dangerous.

This is one of our favorite issues. The Wallarm founders made some money because of it through different bug bounty programs in 2011-2015. Now it’s mentioned in OWASP for the first time. Welcome home!

Actually, XXE is not a bug, but a well-documented feature of any XML parser. Yes, it’s true, an XML data format allows you to include the content of any external text file inside an XML document. To prevent XXE, you should initialize your XML parser in a secure way. Mainly, there are two different options that should be disabled:

  • External entities
  • External DTD schema

And the second one is really important. A lot of problems are caused by this vulnerability based on the external DTD schema even when external entities are disabled. Nevertheless, the OWASP paper has no exploit examples on this matter. Please find it below:

<?xml version=”1.0”?>

<!DOCTYPE a SYSTEM “/dev/urandom”>


The difference is we put a “SYSTEM” attribute to a “DOCTYPE” directive, not to an “ENTITY” itself. Please be careful and fix both!

A5. Broken Access Control

This is a merge of the Insecure Direct Object References and Missing Function Level Access Control from the previous OWASP Top 10 in 2013. It means, according to the whitepaper, that all the issues with authorization are here and even something more. This is strange, but server-side bugs are here together with client-side bugs such as missing CORS policy.

At the same time, a lot of issues such as /.git /log.txt and other classic Insecure Direct Object References should be classified as both A3 (Sensitive Data Exposure) and A5. Moreover, a lot of A2 (Broken Authentication) issues will be classified as A5 as well. As a result, I’d like to say that in my opinion, the set of risks identified by A5 is totally within the A2+A3 union.

A6. Security Misconfiguration

All the default passwords, unpatched software, known issues and just mistakes are here. Technically, it means that all the other OWASP Top 10 2017 risks are here, too. Each time some other OWASP risk triggers, the A6 risk is triggered as well. The reverse is not true. Just because A6 is triggered it doesn’t necessarily mean some other OWASP risk is also triggered. Just remember this.

A7. XSS (Cross-Site Scripting)

I’m sure that everybody knows what this is. But once again, this XSS risk in OWASP does not necessarily mean there is an XSS vulnerability under the covers. The same A7 risk can happen because of Response Splitting (aka CRLF injection), wildcard domains described in crossdomain.xml, Access-Control-Allow-Origin header and others. Keep in mind that OWASP A7 risk can be realized not just through stored (persistent), reflected or DOM-based XSS.

A8. Insecure Deserialization

This is my favorite thing. If you read the previous part of this post, you might have noticed that I’ve already mentioned A4 (XML External Entities, XXE) as my favorite issue. You are right, but I’m right as well at the same time. The fact that XML is a serialization format automatically means that A4 XXE is completely included inside and covered by A8 Insecure Deserialization risk. Everytime we can claim that A4 risk happened, it means immediately that the A8 risk happened as well.

Besides XML, in recent years some other data formats became popular because of the attacks triggered through them. We should remember here OGNL serialization format, which was exploited in Struts2 and was used to hack Equifax in September 2017. Other examples include Java serialization exploits (take a look immediately at the yso tool if you’ve never met it before) for JBoss, Jenkins, Liferay, etc., and Ruby marshaller (aka yaml-exploit).

A9. Known Issues

This is an “I told you so” risk type that we remember all the time when somebody exploits us though a publically available and well known exploit. Obviously, all the other risk types intersect with this risk. I call this risk “lower orbit,” meaning that all the other risks except A6 are located somewhere in this orbit.

A10. Insufficient Logging & Monitoring

This is the risk of unawareness, meaning you should not only have a logging and monitoring system, but also have all the alerts configured. From my point of view, it means that you have the continuous security process established to mitigate this risk. At this point, I can direct you to Microsoft-borne SDL and in particular to the last Response phase, which describes almost the same thing.


OWASP Top 10 is a very useful project that formalizes industry experience and helps the community to address key security risks. However, a lot of security experts and people involved in security have a wrong perception of it as a vulnerability classification system.

It is unreasonable to expect 100 percent protection from OWASP Top 10 risks because some risks are triggered by vulnerabilities that are not yet known and other risks groups are not formally mapped to vulnerability classes.

OWASP Top 10 risk groups have overlaps. Understanding these overlaps and the mapping between the OWASP risks and the actual vulnerabilities is highly important to building a defense-in-depth security strategy that encompasses all layers from architecture to incident response.

Ivan Novikov

Avatar photo

Ivan Novikov

Ivan Novikov is a white hat security professional with over 12 years of experience in security services and products. He is an inventor of memcached injection, and SSRF exploit class as well as a recipient of bounty awards from Google, Facebook and others. Ivan has recently been a speaker at HITB, Black Hat and other industry events. Currently, Ivan serves as the CEO of Wallarm.

ivan-novikov has 2 posts and counting.See all posts by ivan-novikov