Why you shouldn’t use the OWASP Top 10 as a list of software security requirements

posted on Jan 16, 2013 by Rohit Sethi

On February 15, the Open Web Application Security Project (OWASP) came out with its 2013 list of candidates for the Top 10 web application security flaws. This list is available here and open for public comment – the final Top 10 list will come out in April or May. If it’s anything like previous years, OWASP Top 10 2013 will become the de-facto yard-stick that organizations use to test if their applications are secure. This is at least partially because the Payment Card Industry Data Security Standards specifically enumerates the OWASP Top 10.

The challenge is that while the Top 10 details security flaws, these flaws don’t map cleanly to requirements. To understand this, let’s look at one of the current OWASP Top 10 flaws A3: Broken Authentication and Session Management. How do you assert that you aren’t vulnerable to A3? Unlike, say, Cross Site Scripting, where you might know specifically what to look for (proper input validation and output escaping), this flaw is actually a broad class of vulnerabilities. For example, there are certain very common vulnerabilities:

  • Are you hashing and salting user passwords?
  • Are passwords sufficiently encrypted during transmission?
  • Is the ‘forgot password’ mechanism protected against brute-force attacks?

At the same time, there are several other kinds of threats specific to particular technology stacks:

  • If relying on X509 mutual authentication, are you verifying the certificate chain of trust?
  • If implementing SAML are you using HTTP Post binding instead of HTTP Redirect binding to avoid data being cached/observed on proxy nodes along the way?
  • If implementing  a custom session management mechanism, do the sessions have sufficient entropy to prevent being guessed?

In our experience, few organizations go to the level of detail of outlining which specific requirements they are assessing. Instead, they may run the application through a scanning solution which only tests against a small subset of the above threats, and declare that they’ve accurately assessed A3.  In other cases, they may have a penetration tester run an opaque set of tests against the application and declare that they haven’t found any authentication or session management vulnerabilities.  OWASP has long understood this, and has gone to the length of creating the much more comprehensive Application Security Verification Standard (ASVS) project. Unfortunately, that project has only a fraction of the attention of the Top 10 project.

In addition to the breadth of specific threats, the other obvious issue with using the OWASP Top 10 as a yard-stick is that it can completely leave out very serious security vulnerabilities for a particular application. For example, a Rails application may be vulnerable to Mass Assignment vulnerability and it won’t be assessed simply because it wasn’t defined as one of the Top 10.

The OWASP Top 10 is a great awareness tool, but it’s not a substitute for a tailored set of software security requirements.

Automated Scaling of Security Requirements

  • Rob Barnes


    I agree completely with your post, and I would even offer that we as security practitioners are doing a disservice to our customers (internal or external) when we report vulnerabilities using the language of the OWASP Top 10. What does “broken session management” mean to a business stakeholder? It probably means the same thing as when my mechanic tells me that my exhaust gas recirculation valve needs to be replaced. The same two questions can be asked: 1) How much does it cost, and 2) what happens if I don’t fix it?

    We should speak the language of the business and instead of reporting a “broken session management” vulnerability, we should report that an attacker sitting in a coffee shop (or on a school campus or in the office next door) can access the application by assuming the identity of an authorized user over an unsecured wireless network.

    Painting the picture of an attack scenario better conveys how vulnerabilities directly affect business objectives.