owasp top ten blog1.png

The OWASP Top 10 has been leveraged by organizations of all sizes and maturity as an informal Web application standard for over a decade. For it to be relevant though, teams applying it need to understand the goal of the project and risk ranking techniques. [Webinar] The OWASP Top Ten 2017 - Let's Cut to The Chase on Wed., FEB 7th, at  1PM EST. Save Your Seat!

The goal of the OWASP Top 10 is not necessarily to identify top vulnerabilities or attacks, but to identify the most serious risks for a broad array of organizations. This is an important distinction because it can change how you think about this list. They are ranked in order of their risk based upon their risk rating system, which includes how prevalent (common) the issue is, how difficult it is to exploit, how easy it is to find, and how severe its impacts are. This is similar approach to how we risk rate vulnerabilities identified during software security assessments in client software. 

The list includes:

  1. Injection
  2. Broker Authentication
  3. Sensitive Data Exposure
  4. XML External Entities (XXE)
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Script (XSS)
  8. Insecure Deserialization
  9. Using Components with Known Vulnerabilities
  10. Insufficient Logging and Monitoring

Go beyond the scan. Sign-up to learn about our OWASP Assessments 

These new entries seem to be the result of other risks being mitigated more easily, not because they are necessarily more prevalent. 

A4-XML External Entities (XXE)
is actually an injection type vulnerability.  The fact that it is a category of its own, when all other Injections are lumped into A1, is favorable because general awareness of it is low and prevalence is high. XXE is something that our services team uncovers in approximately one in every fifteen penetration tests - and it usually has a severe impact and is relatively easy to find and exploit.  I don't necessarily agree with the notion that it is found by automation/source code tools any more than through pen testing – perhaps our engineers just have a propensity to “follow our nose” towards XXE whenever we see data being stuffed in to XML documents (a good thing IMO) J

A8 -Insecure Deserialization

This permits remote code execution or sensitive object manipulation on affected platforms.  This is an important addition that could also be considered a type of Injection vulnerability. Deserialization occurs when a piece of data is turned into an object that is internal to the application. This vulnerability is primarily applicable to object-oriented programming. For example, an application might work on a class called "human", which has member variables like age, name, and address. Objects of this class have to be serialized to be stored on disk and then deserialized to be loaded back into the application. When this deserialization takes place, often types a function is invoked to do some kind of processing on that data being loaded, like say checking if today is the person's birthday, or maybe error handling if the data is not valid. If there is a vulnerability in the functions that are invoked during deserialization, then the data being deserialized can be used to exploit the vulnerabilities in these functions. This is quite an insidious vulnerability that often results in arbitrary code execution.

A10 -Insufficient Logging and Monitoring

Implementing proper logging and monitoring controls can help identify malicious activity and improve breach detection, incident response, and digital forensics.  This is a category that indicates a step forward for application security as a whole. Ultimately, it is important to know whether your application or system is currently compromised or not and the best way to accomplish this is to implement logging and monitoring. The better, and the more relevant, the logging data produced by the application, the more likely you are to accurately determine what the status of your system currently is and what it has been in the past. Absence of this information can make the task of determining whether an attack has been successful very difficult or impossible and that can be arguably considered a vulnerability in itself.


A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5 -Broken Access Control. 

Combining A4 and A7 into A5 makes sense because both Insecure Direct Object References and Missing Function Level Access Control are ultimately the result of incorrectly implemented access control. Missing Function Level Access Control is the lack of access control checks altogether when some functionality is being invoked, as the name suggests. Insecure Direct Object References occur when an attacker is able to access objects for which they have no authorization. Both of these vulnerability types are essentially two sides of the same coin, where one deals with invoking application functionality and the other with accessing system objects. Preventing both of these vulnerability types requires consistently applying an effective access control model throughout the application, so the name Broken Access Control is accurate and intuitive at describing both of them. It’s encouraging to see that OWASP spends time thinking about redundancy and overlap. 

A8-Cross-Site Request Forgery (CSRF). 

This attack was first introduced into the 2nd version of the Top 10 in 2007.   Frameworks commonly include CSRF defenses so this risk fell to #13.  This was a little surprising but the data supports it.

A10-Unvalidated Redirects and Forwards

With less than 1% of the data set supporting this issue today, this fell to #25.  While I generally agree that it’s not a top ten issue, such a drastic drop but might cause them to resurface later if a new generation of developers become ill informed of them.

Overall I think the changes of the OWASP Top ten reflect the times and are good changes that make sense considering the education and new frameworks we have available to us as developers. This shows the progress that’s been made to secure web applications and the progress that is still ahead of us.

Get the Newsletter

Every two weeks we'll send you our latest articles along with usable insights into the state of software security.

Posts by Topic

View Full Topic List