For the first time since 2013, the Open Web Application Security Project (OWASP) has updated its top 10 list of the most critical application security risks. According to OWASP, the 2017 OWASP Top 10 is a major update, with three new entries making the list, based on feedback from the AppSec community.
This update went through two versions. After the initial release candidate in April 2017 got big push-back from the AppSec community, OWASP went back to the drawing board and issued a new draft in August seeking community feedback, and a final updated Top 10 list in November. This time around, there seems to be more consensus. One thing everyone agrees on: an update to the Top 10 was needed. “Change has accelerated over the last four years, and the OWASP Top 10 needed to change,” OWASP said in the forward to the 2017 release.
The OWASP Top 10 is an influential and widely used AppSec standard – lots of organizations rely on it for direction in their AppSec programs.
Veracode supports the OWASP Top 10 throughout the Veracode product suite. The Veracode platform allows users to customize their security policy in alignment with this and other industry standards. Veracode’s flaw and vulnerability checks are regularly updated to match industry requirements. Veracode’s developer education courses include OWASP Top 10 materials as well as deep dives into categories disallowed under the industry standard. Veracode contributed a significant percentage of the data used to determine this latest Top 10 and works closely with industry organizations including both OWASP and MITRE to promote software security awareness and enhance understanding of security vulnerabilities.
In this blog post, we explain more about the three new risks in the 2017 top 10, what else has changed since 2013, and provide resources exploring best practices for preventing these risks. Check out our infographic describing all 10 risks, and visit our OWASP Top 10 resources page.
What’s new in the 2017 OWASP Top 10?
Three web application risks were added to the 2017 OWASP Top 10.
XML external entities (XXE)
Coming in at number four on the 2017 OWASP Top 10 list is XML external entities. This risk refers to poorly conﬁgured XML processors that evaluate external entity references within XML documents. Attackers can use external entities for attacks including remote code execution, and to disclose internal ﬁles and SMB ﬁle shares.
- Veracode recommendation: Static application security testing (SAST) can discover this issue by inspecting dependencies and conﬁguration.
Insecure deserialization is ranked at number eight on the 2017 OWASP Top 10 list. Insecure deserialization ﬂaws can enable an attacker to execute code in the application remotely, tamper or delete serialized (written to disk) objects, conduct injection attacks, and elevate privileges.
Insecure deserialization was on the rise in the past year. Veracode research for our State of Software Security report found that 53.3 percent of Java applications were using a version of the Apache Commons Collections library with an insecure deserialization vulnerability, up from 49 percent the previous year.
- Veracode recommendation: Application security tools can detect deserialization ﬂaws, but penetration testing is frequently needed to validate the problem. Software composition analysis can help determine if applications are using an insecure version of components like Apache Commons Collections.
Insufficient logging and monitoring
The final new entry in this year’s OWASP Top 10, ranked at number 10, is insufficient logging and monitoring. Insufficient logging and ineffective integration with security incident response systems allow attackers to pivot to other systems and maintain persistent threats for weeks or months before being detected.
With attackers frequently exploiting new vulnerabilities within days of disclosure, logging and monitoring is critical to responding to all of the other nine risks in the OWASP Top 10, particularly number nine, using components with known vulnerabilities.
- Veracode recommendation: Think like an attacker and use pen testing to ﬁnd out if you have sufficient monitoring; examine your logs after pen testing.
Some risks from the 2013 OWASP Top 10 were dropped or merged in 2017
The ordering of the top 10 is based on prevalence of risks, and some of the risks have been re-ordered between the 2013 OWASP Top 10 and the 2017 version to reflect that.
Two risks on the 2013 version of OWASP Top 10 have been dropped out of the top 10 in 2017: cross-site request forgery (CSRF), and unvalidated redirects and forwards. These risks are “gone, but not forgotten,” OWASP said.
Another two risks from the 2013 version were merged in the 2017 OWASP Top 10: Insecure direct object references and missing function level access control were merged into broken access control.
|OWASP TOP 10 2013||OWASP TOP 10 2017|
|1. Injection||1. Injection|
|2. Broken Authentication and Session Management||2. Broken Authentication|
|3. Cross-Site Scripting||3. Sensitive Data Exposure|
|4. Insecure Direct Object References (Merged in 2017 with #7)||4. XML External Entities (NEW)|
|5. Security Misconfiguration||5. Broken Access Control (MERGED)|
|6. Sensitive Data Exposure||6. Security Misconfiguration|
|7. Missing Function Level Access Control (Merged in 2017 with #4)||7. Cross-Site Scripting|
|8. Cross-Site Request Forgery (DROPPED in 2017)||8. Insecure Deserialization (NEW)|
|9. Using Components With Known Vulnerabilities||9. Using Components With Known Vulnerabilities|
|10. Unvalidated Redirects and Forwards (DROPPED in 2017)||10. Insufficient Logging and Monitoring (NEW)|
For a more complete view of what’s in the OWASP Top 10, and what’s changed, check out the infographic at the bottom of this blog post.
OWASP recommendations for securing web applications
OWASP released a set of recommendations, describing what’s next for developers, application security testing processes, and organizations looking to begin the process of securing their applications.
Developers: Establish and use repeatable security processes and standard security controls.
- Follow the secure development lifecycle, design security from the start, and educate yourself in AppSec practices.
Security testing: Establish continuous application security testing.
- Make testing compatible with the software development lifecycle (SDLC)
- Focus on what’s important before expanding your program over time
- Communicate security findings effectively.
Organizations: If you haven’t already, start your application security program now.
- Use a risk based portfolio approach
- Establish policies, training, and support for developers and project teams
- Integrate testing into existing processes
- Manage with metrics.