Top Web App Security Risks

Thursday, June 13, 2013 @ 03:06 PM gHale

Code injections remain the top web application security risk, according to a new report put out by the Open Web Application Security Project (OWASP).

Updating its Top Ten list from 2010, the organization said threats from cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks went down in importance and problems with broken authentication and session management procedures moved up into the second spot.

Mobile Security Costs Companies
BYOD Dilemma: Risky Apps
Federal Security Guidelines Reworked
Firing Up a Security Framework

The OWASP Top Ten report published for the first time ten years ago and is a valuable resource among web developers and security experts.

The report comes out every three years and its focus shifted more toward general security risks instead of potential vulnerabilities. The newest report was the result of compiling information on over 500,000 vulnerabilities in several thousand applications from hundreds of companies.

OWASP Web App Security Risks
1. Injection (1)
2. Broken Authentication and Session Management (3)
3. Cross-Site Scripting (XSS) (2)
4. Insecure Direct Object References (4)
5. Security Misconfiguration (6)
6. Sensitive Data Exposure (7/9)
7. Missing Function Level Access Control (8)
8. Cross-Site Request Forgery (CSRF) (5)
9. Using Known Vulnerable Components (-)
10. Unvalidated Redirects and Forwards (10)
Position in the 2010 report shown in brackets.

OWASP merged the entries for insecure cryptographic storage and insufficient transport layer protection into a new category called “sensitive data exposure” that deals with security problems arising from data leaks in general.

Similarly, the 2010 entry for “failure to restrict URL access” broadened into a more general entry for problems with function-level access control because there are many ways, not just via URLs, to access the functionality of a modern web application.

A new category came into play for administrators who use known vulnerable components such as libraries, frameworks and modules. In the report from three years ago, this was included within the “security misconfiguration” category, but OWASP said this problem has become important enough to warrant its own entry on the list.

Leave a Reply

You must be logged in to post a comment.