OWASP Top Ten 2017 Release Candidate is out (and how it affects you)
Yesterday, the Open Web Application Security Project published the Release Candidate of the ten most critical Web application security risks in the OWASP Top Ten 2017. OWASP is instrumental in raising awareness about the most critical security issues affecting Web applications these days – and in today’s connected world, the security of Web applications is more critical than ever.
In the last decade the OWASP Top Ten list became the most important reference point with respect to Web application security trends, such as:
- Which vulnerabilities are becoming more critical due to the prevalence of poor development practices – or, conversely, the discovery of new attack techniques;
- Which risks have become less significant over time due to the adoption of effective best practices and countermeasures and; and finally
- What completely new threats have appeared due to changes in the design and implementation of web applications, such as moving towards cloud-based deployments with a large number of external dependencies.
In the end, such lists are handy to prioritize threats when developing your application. However, keep in mind that such a top list is definitely not an exhaustive list of security problems, and should not be used as such. It is not a checklist and neither is it something one can “comply” with; it is just a starting point of a journey through Web application security!
The changes of the 2017 release candidate as compared to the previous 2013 list are relatively minor:
Source: owasp.org
- The old A7 – Missing Function Level Access Control was merged with A4 – Insecure Direct Object References now forming the new A4 – Broken Access Control.
- A7 – Insufficient Attack Protection and A10 – Underprotected APIs are two new risks on the list.
- Finally, the old A10 – Unvalidated Redirects and Forwards fell out from the new top ten.
So what do these changes tell us about the current trends from a secure coding standpoint?
The first change is actually just bookkeeping – Broken Access Control was originally present in earlier Top Ten lists, undergoing various splits and merges over time. Thus, both merged risks remain as important as ever under this new category.
However, the appearance of the two new risks – Insufficient Attack Protection and Underprotected APIs – highlights something more interesting: neither is connected only to the code and the implementation of the web application, rather they reflect threats stemming from the environment and the various components providing APIs – such as libraries, web services or microservices. Reliance on third-party components vastly increases the exposure of a system to potentially malicious interactions, and the attack surface is extended beyond just the developer’s own code. This is becoming more and more an aching point for software development projects; the two new items continue the trend that already started in 2013 by introducing Using Components with Known Vulnerabilities as a new component of the top ten list.
Insufficient Attack Protection refers to the inability to detect, prevent and respond to various kinds of attacks against the application as a whole. This – due to the large number of unaudited third-party components that may contain critical vulnerabilities – necessitates the use of generic security tools such as intrusion detection systems (IDS), and web application firewalls (WAF) that can identify an ongoing attack such as SQL injection. It focuses on the consequences instead of the root causes of the weaknesses.
Underprotected APIs looks at the problem from the other direction: with web applications increasingly relying on web services – both public APIs as well as the web application’s own core functionality implemented as a set of Internet-facing microservices – developers often forget that the attackers can access these APIs directly as well, and they don’t get the level of scrutiny that they deserve.
All in all, the 2017 OWASP Top Ten shows a continued shift towards merging AppSec and OpSec – it’s not just about making sure your own code is secure, it’s also about adding assurances that other code will not be able to harm your system, even if they include vulnerabilities (or just misbehave). In the age of rapid application development, Agile, and DevOps, maybe one of the current combo-buzzwords (DevOpsSec, SecDevOps or DevSecOps) will emerge as the path to take.
SCADEMY Secure Coding Academy courses already cover the current release candidate of the OWASP Top Ten; visit our course catalog to check our Web application security courses.