OWASP Top 10 – 2013 Web Application Security Risks

Owasp Top 10 2013
OWASP Top 10 2013

OWASP TOP 10 list is being constantly updated every 3 years to keep pace with the current threat landscape for web application security. Key factors in its evolution are advances made by attackers, the release of new technologies with new weaknesses, more built in defences, and the deployment of increasingly complex systems.

On June 6, 2013, OWASP foundation released the official updated Top 10 web vulnerabilities list for year 2013 onwards. Here is the brief snapshot of the changes observed in OWASP Top 10 list:
Trends observed in new OWASP Top 10 2013 from 2010 list are:

a) Position Swaps:
Broken Authentication and Session Management moved up at No.2 position. This was done since this vulnerability is getting more focus in recent times than Cross Site-Scripting. Subsequently, Cross-Site Scripting is now positioned at No. 3.

b) Moving down the top 10:
Cross-Site Request Forgery (CSRF) vulnerability position is now at No. 8. Since CSRF has been in Top 10 category for more than 6 years, developers have routinely developed enough safeguards against this vulnerability in their web application(s) reducing its likelihood of occurrence.

c) Moving up the OWASP Top 10:

Failure to Restrict URL Access has now been broadened and renamed to include function level access control. Further, its position has now been promoted to (A7) from (A8) in 2010 Top 10 list. Final position: A7- Missing Function Level Access Control

d) New Additions:
The new list has the following new additions:

  • Position A6: Sensitive Data Exposure is created. This is basically the merging of 2 issues in 2010 OWASP Top 10 List namely
    • 2010-A7 Insecure Cryptographic Storage and
    • 2010-A9 – Insufficient Transport Layer Protection.

    This category is concerned only when sensitive data is provided by the user, stored within the application, and then sent back to the browser again.

  • Position A9: Using Known Vulnerable Components has been created. The growth and depth of component based development has significantly increased the risk of using known vulnerable components.


Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.