OWASP Top 10 Gets A Makeover

For those of you who are not familiar with the OWASP Top 10, it is a great set of vulnerabilities to check your web application for.  If your software QA team, in addition to the normal functional stuff that they check for can also check for these exposures, that will likely catch a number of bugs.  While nothing is perfect, if you don’t have a huge QA budget, using this list is a great first step toward improving software reliability and security.

Every few years the Open Web Application Security Project revises their top 10 list of vulnerabilities.  For the most part, the items remain the same, but one or two items change.

Going back to 2010, here is the top 10 list (note that each item is a clickable link – if you dare):

• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards

The next time it was revised was in 2013 and here is that top 10 list:

• A1 Injection
• A2 Broken Authentication and Session Management
• A3 Cross-Site Scripting (XSS)
• A4 Insecure Direct Object References
• A5 Security Misconfiguration
• A6 Sensitive Data Exposure
• A7 Missing Function Level Access Control
• A8 Cross-Site Request Forgery (CSRF)
• A9 Using Components with Known Vulnerabilities
• A10 Unvalidated Redirects and Forwards

You can see that there is a lot of similarity, but a couple of items changed and the order changed.

It looks like about every 3-4 years they update the list so now is the time to make the next change.  Here is the proposed draft list for 2017.  It will be finalized in July or August.  You will notice that the 2010 and 2013 lists have live links to more information.  Apparently because the 2017 list is still a draft, that isn’t the case, so here is that list.  You can go to OWASP’s web site (OWASP.Org) to get more information.

• A1 – Injection
• A2 – Broken Authentication and Session Management
• A3 – Cross site scripting (XSS)
• A4 – Broken Access Control (Original category in 2003/2004)
• A5 – Security misconfiguration
• A6 – Sensitive data exposure
• A7 – Insufficient attack protection (NEW)
• A8 – Cross site request forgery (CSRF)
• A9 – Using components with known vulnerabilities
• A10 – Underprotected APIs (NEW)

Their explanation for the changes this time are:

1) We merged 2013-A4: Insecure Direct Object References and 2013-A7: Missing Function Level Access Control back into 2017- A4: Broken Access Control

In 2007, we split Broken Access Control into these two categories to bring more attention to each half of the access control problem (data and functionality). We no longer feel that is necessary so we merged them back together

2) We added 2017-A7: Insufficient Attack Protection

For years, we’ve considered adding insufficient defenses against automated attacks. Based on the data call, we see that the majority of applications and APIs lack basic capabilities to detect, prevent, and respond to both manual and automated attacks. Application and API owners also need to be able to deploy patches quickly to protect against attacks

3) We added 2017-A10: Underprotected APIs:

Modern applications and APIs often involve rich client applications, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities. We include it here to help organizations focus on this major emerging exposure.

4) We dropped: 2013-A10: Unvalidated Redirects and Forwards:

In 2010, we added this category to raise awareness of this problem. However, the data shows that this issue isn’t as prevalent as expected. So after being in the last two releases of the Top 10, this time it didn’t make the cut.

So again, if your organization develops web apps, this list should be pinned to the wall of every developer cube and it should be part of the todo list for QA.

For more information visit the Owasp web site at www.owasp.org.

by