March 27, 2018

Last Updated on January 19, 2024

The “OWASP Top 10” list of the most critical web application security risks is widely used as a basis for application security testing and as high-level guidance for assessing risks and prioritizing remediation of vulnerabilities. Recently, for the first time since 2013, OWASP revised the list.
The update is significant, reflecting widespread and accelerating change in web application development approaches, such as the use of microservices and the dominance of JavaScript and modern web frameworks like Node.js on the server and Bootstrap.js, Angular.js, etc. on the client. One result of these changes is that certain “legacy” vulnerabilities are becoming less prevalent, while others are on the rise.

The New OWASP Top Ten

Three “new” vulnerabilities were added to the Top 10 for 2017, two vulnerabilities from the 2013 list were rolled into one, and two vulnerabilities were dropped from the list (not without controversy). OWASP also made some minor updates to the attack scenarios.
Here is a quick rundown of the new OWASP Top Ten 2017 list: 

A1:2017—Injection

Injection attacks (primarily via SQL, LDAP or operating system vectors) continue to top the charts, as many applications are still vulnerable to these high-risk attacks that frequently result in data breaches. Many of the penetration tests I personally have conducted recently have turned up this vulnerability in a wide range of applications.

A2:2017—Broken Authentication

This vulnerability kept its position from 2013, but its title was simplified. It still pertains to loopholes in username, password and session management functions; e.g., session hijacking.

A3:2017—Sensitive Data Exposure

This issue moved up from #6 in 2013, due to an increasing number of attacks targeting it. Many applications continue to store sensitive data as clear text, and/or failing to apply security directives or headers effectively.

A4:2017—XML External Entities (XEE)

Here we find the first of the new entries for 2017. OWASP included XEE because of its greatly increased relevance as more applications use web services. Its focus is on issues with older or misconfigured XML parsers and usage of the SOAP framework.

A5:2017—Broken Access Control

The new #5 reflects the merger of #4 (Insecure Direct Object References) and #7 (Missing Function Level Access Control) from 2013. Personally, I like this change because it puts focus on the bigger issue of access control vulnerabilities (e.g., privilege escalation, cross-origin resource sharing, misconfigurations, etc.) instead of on specific aspects of it.

A6:2017—Security Misconfiguration

Down from #5 in 2013, the scope of the vulnerability remains similarly broad-based: misconfigured application servers, misconfigured security settings in the application framework, and so on. OWASP also put strong emphasis on cloud service misconfigurations, which have resulted in so many high-profile data breaches as applications move to cloud environments.

A7:2017—Cross-Site Scripting

Though it’s been bumped down from #3 to #7 for 2017, XSS remains the second most prevalent issue among web applications—found in two-thirds of applications tested, according to OWASP. The range of XSS attacks on users can result in exfiltration of data, installation of malware and even complete account compromise. Code review remains the best way to identify specific XSS vulnerabilities in applications.

A8:2017—Insecure Deserialization

This is a new addition to the Top 10, by popular demand of the user community. Leveraging application classes that can change behavior during or after deserialization, these flaws can permit remote code execution or manipulation/tampering of sensitive data on the affected platforms.

A9:2017—Using Components with Known Vulnerabilities

Holding on at #9 from the 2013 list, high-profile attacks targeting vulnerable, unsupported or out-of-date components continue unabated. The growing use of components and APIs can complicate finding these vulnerabilities and keeping third-party code up-to-date. As OWASP puts it: “Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.”

A10:2017—Insufficient Logging and Monitoring

Last but not least for 2017 is this new entry, introduced based on community feedback, which focuses on issues with application logging of key activities like logins, failed logins, warnings, high-value transactions, etc. It also covers issues around storing and protecting log data from tampering/misuse.

Conclusions

Gone from the 2017 list are the former A10 (Unvalidated Redirects and Forwards, which now affects only about 8% of applications), and the fearful former A8, Cross-Site Request Forgery (CSRF).
The rationale for dropping CSRF is that many modern programming language frameworks offer “built-in” defenses against CSRF by default, so that its prevalence has dropped below 5% of applications. However, CSRF vulnerabilities still pose high risks and new flaws continue to surface regularly (e.g., a newly discovered, critical flaw in the popular phpMyAdmin application).
To defend against OWASP Top 10 flaws, developers need to establish and use repeatable processes and security controls, security testers need to establish continuous application security testing, and application managers/owners need to take charge of the full application lifecycle from a security perspective. Further, the business as a whole needs to have an application security program in place.
To tap into expert guidance to optimize your application security program, policy, procedures and DevOps pipeline to reduce risks to your business and its customers, contact Pivot Point Security.

Free OWASP ASVS Testing Guide

If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!