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

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

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.


Previous Article
4 Reasons Why Developers Don’t Read Secure Programming Guides
4 Reasons Why Developers Don’t Read Secure Programming Guides

At Security Compass, we had the experience of building secure programming guideline documents for a number ...

Next Article
Making Security Requirements a Reality
Making Security Requirements a Reality

We’ve released a whitepaper: Automated Scaling of Security Requirements. It describes the motivation and me...