You are here

You are here

OWASP Top 10 2017: What your app sec team needs to know

John P. Mello Jr. Freelance writer

The new OWASP Top 10 traveled a rocky road this year, but the final version is out, and it includes both changes and new risks you'll want to address. 

The first release candidate of what's become a critical list for developers seeking to make their applications more secure was derailed halfway through the year by some controversial changes. Fortunately, a new leadership team managed to get the project back on the rails and on a fast track to completion. The final version released on November 21.

"Overall I'm surprised and pleased at how effectively the OWASP Top 10 team has addressed community feedback and responded with a solid new release candidate," said James Kettle, head of research at PortSwigger Web Security, a web application security testing company.

Having an up-to-date OWASP Top 10 is important because of the role the list has assumed in the development and security communities, explained Ed Moyle, director of thought leadership and research at ISACA.

"In essence, placing something on the Top 10 makes it a de facto regulatory requirement for much of industry—certainly for merchants, but also for financial services organizations, payment processors, and, by extension, cloud and other providers that service those entities. So it’s a big deal."
Ed Moyle

The final version of the list, based on Release Candidate 2, retains several of the web application security risks from 2013, the last time the list was revamped. These include injection, broken authentication and session management, sensitive data exposure, security misconfiguration, cross-site scripting, and components with known vulnerabilities.

Two items from the 2013 list—insecure direct object references and missing function-level access control—were merged into a single item: broken access control. Three new risks were added: XML external entity, insecure deserialization, and insufficient logging and monitoring. Two items have been removed: Cross-site request forgery (CSRF) and unvalidated redirects and forwards. 

Here are the key takeaways for the final OWASP Top 10 2017.

Better recognition of dependencies

"There's a lot of good in [OWASP Top 10 2017]," said Scott Crawford, research director for information security at 451 Research. More attention is being paid to data and functionality that applications accept from external entities. "That wasn't included in previous versions of the Top 10," he said.

"It addresses the more distributed nature of applications and brings it more up to date and in line with current practice in applications."
Scott Crawford

The new list also removes items proposed in the previous release that were outside a developer's realm, said Alvaro Muñoz, principal software security researcher for Micro Focus. 

"The OWASP Top 10 should be a list of risk to help developers prioritize their security efforts, because developers don't have time to learn about every single kind of vulnerability and attack."
Alvaro Muñoz

The first release candidate proposed items such as insufficient attack protection, which is fixed by running a web application firewall or RASP. "That's not something developers need to act on," Muñoz said. "It's something the security guys in a company should care about, but it shouldn't be on a list for developers."

Logging and monitoring

While insufficient attack protection isn't mentioned by name, it hasn't disappeared completely from this year's list. Insufficient attack protection has been toned down and rebranded as the new A10 on the list: insufficient logging and monitoring, PortSwigger's Kettle said.

"Although it still appears slightly incongruous placed next to a list of nine vulnerability classes, it no longer demands complex and potentially harmful measures like active defense," Kettle explained. "It also no longer recommends immature, big-money technologies such as RASP, making it appear less like a blatant vendor pitch."

Like insufficient attack protection, insufficient logging and monitoring are about the absence of a countermeasure, rather than addressing a specific attack pattern, said ISACA's Moyle. "However, the new A10 should pose less of a problem for organizations because regulators have requirements around logging already in place," he added.

Insufficient logging and monitoring is a long-standing issue for applications, 451's Crawford noted. "I'm glad to see that one make it into the list because it bedevils security people," he said.

"[It's difficult] to pinpoint where and how their systems have been penetrated or exploited through an application unless the application gives you some indication that something has gone wrong."

If your developers haven't built anything into their apps to catch access-error situations, they may not get reported as an event to any kind of monitoring system, Crawford said. That means you'll have to find evidence in transaction records to see if an application was compromised. "It leaves organizations too blind to issues that they should be paying close attention to."

"Encouraging developers to add logging and monitoring as a part of normal application functionality is something that's been needed for a long time."

XML risk

An addition to the OWASP Top 10 that surprised some security pros was the XML external entity risk. According to the RC2 team (PDF), many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal Server Message Block file shares on unpatched Windows servers, internal port scanning, remote code execution, and denial-of-service attacks, such as the Billion Laughs attack.

"I'm surprised [the XML risk] is as high up on the list as it is," said Mic Whitehorn-Gillam, a senior security consultant with Secure Ideas, a security testing, training, and consulting company. "They're working off the dataset they have, which is larger than my personal dataset, but I don't encounter a context where that's even a potential very often, and I'm testing an app every week or every other week.

"It's a significant issue when it's present, but I wouldn't have expected to be as prevalent as they've indicated it is."
Mic Whitehorn-Gillam

That the XML risk was placed higher on the list than cross-site scripting also surprised Micro Focus' Muñoz.

"To me, cross-site scripting should be number one or two. XML used to be vulnerable by default, but now most of the libraries around XML parsing, like the ones provided by Oracle or Apache, all have secure defaults."


Insecure deserialization flaws occur when an application receives hostile serialized objects and can lead to remote code execution, the Top 10 team explained. Even if deserialization defects do not result in remote code execution, serialized objects can be replayed, tampered with, or deleted. These, in turn, can spoof users, conduct injection attacks, and elevate privileges.

Deserialization risks have been known since 2011, but concern about them didn't heat up until Chris Frohoff and Gabriel Lawrence discovered them in the Apache Commons Collections libraries back in 2015.  Deserialization became even more of a problem in 2016, Muñoz noted.

"Because many applications import those libraries, all of a sudden attackers were leveraging the libraries to get remote execution of code... There was an explosion of vulnerabilities related to Java deserialization."

Goals should be achievable by all

One of the most important departures by this latest Top 10 list from the previous release candidate is the recognition that the risks on the list need to be addressed by a variety of practitioners. "We need to make sure that a small project, like a one- or two- person project, can solve the OWASP Top 10 by themselves without buying anything," one of the RC2 leaders, Andrew van der Stock, said in a podcast in September.

The OWASP Top 10 is a baseline that should be achievable by everyone, added project leader Brian Glas. "We can't take the Top 10 to super-advanced stuff, whether or not we want to," he said. 

A baseline has to be something that's actionable and can actually be accomplished by different sized teams, Glas noted.

"You shouldn't need to have a 10-person security team and at least 400 developers and a whole program to meet that baseline."
Brian Glas



Keep learning

Read more articles about: SecurityApplication Security