The OWASP Top 10 list is well known as the industry standard for what matters in web security. The list, which ranks the most critical risks organizations face through their web applications, was recently updated. The 2013 Top 10 List features some incremental but noteworthy changes that point to the project’s maturity.
Perhaps the most significant change to the Top 10 list is the moving of “cross-site scripting” (XSS) from its No. 2 spot to No. 3. This is a big change because web security was built on two things: SQL injection and XSS. Almost every browser these days has some level of XSS prevention, so it’s more difficult to deliver a XSS payload to a user. As a result, XSS represents less of a risk.
By moving to No. 3, XSS switched places with “broken authentication and session management,” which moves up to No. 2 from No. 3. Broken authentication and session management isn’t well understood by most developers, and I suspect that’s why it’s moving up. We see a lot of weak authentication and session management schemes. Developers just aren’t doing a good job with it. But they’re going to have to, because this is a new attack vector that will really matter in the future, especially with the move to mobile.
The OWASP also renamed what was previously “failure to restrict URL access” to “missing function-level access control” and moved it up one spot, from No. 8 to No. 7. This makes sense since it doesn’t matter how access is presented. It is either restricted or it’s not.
“Insecure cryptographic storage” and “insufficient transport layer protection” were also combined and renamed “sensitive data exposure,” which came in at No. 6. This essentially merges the encryption layer, which makes sense. Sensitive data should be transported over a secure channel and stored in a secure manner. You’re dropping the ball if you do one and not the other.
OWASP also added an item to the Top 10 that I think is long overdue. “Using known vulnerable components” deserves its spot at No. 9. Developers have long used shared libraries and open source code, and oftentimes these components have vulnerabilities that affect the software built with them. This has gone on since the days of PHP-Nuke. I’m shocked that it wasn’t on the list before because it seems so obvious, but maybe that’s why it was overlooked.
Finally, the last change I’d like to point out is also one that I don’t necessarily agree with. That’s the drop that “cross-site request forgery” (CSRF) made from No. 5 to No. 8 on the list. We still see a lot of CSRF, partly because automated testing tools just aren’t good at detecting it. It’s becoming increasingly difficult to test for these vulnerabilities and to know when you need CSRF protection. Unfortunately, it still happens a lot and when an attack is successful it can have significant repercussions – especially when combined with XSS.
The changes that we see in the OWASP 2013 Top 10 won’t impact most people because they are incremental, but overall these changes bode well for the list. It’s getting leaner and better. That’s a sign of the project’s maturity.
” Developers have long used shared libraries and open source code, and oftentimes these components have vulnerabilities that affect the software built with them.”
I’m glad this is on the list as well. A huge percentage of open source code components have security issues but they get used anyway because it’s fast and convenient and a good fix for the present issues. But when you’re developing software you HAVE to think long term and that means making them as secure as possible.