Now that security pros have a refreshed list of the 10 most critical web application security risks—known as the OWASP Top 10—they have a good place to start making their online apps more secure. But security shouldn't begin and end with the OWASP list.
Since the first Top 10 debuted in 2003, the list has increased in stature as a security measure. As the project team noted when it released the 2017 list, "Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers, it has become the de facto application security standard."
The list gained standard status for several reasons. For one thing, it is short and simple. Web application security is complicated. The OWASP Top 10 simplifies it and gives a web developer or development team something easily digestible on which they can focus.
In addition, many dynamic and static testing tools began incorporating the Top 10 as a benchmark. They offered reports for developers to see how their code fared against the OWASP Top 10. Those reports could be used as evidence that an organization's security efforts were in compliance with industry best practices.
[ A Developer’s Guide to the OWASP Top 10 ]
Finally, the Top 10 began to be referenced in industry and government standards. For example, organizations that want to perform credit card transactions need to comply with the Payment Card Industry (PCI) data security standard. To be in compliance with PCI, the outfits need to be testing for OWASP Top 10 vulnerabilities.
Even the OWASP Top 10 2017 project team offered a word of caution to those using the list. There are hundreds of issues that could affect the overall security of a web application, they explained. In this year's Application Security Research Update report, Micro Focus found that 49% of discovered vulnerabilities were not covered by the Top 10 list.
Here's a full rundown on why security practitioners need to look beyond the OWASP Top 10 if they want to effectively find vulnerabilities in web applications and APIs.
App sec is a journey
"If you look at the OWASP Top 10 as a list, it's fairly good," Vishal Asthana, director of customer solutions at Security Compass, said recently.
"If I'm a web developer, I need to look at this to get a good, holistic idea of what I need to be doing. The problem is that's where people stop."
—Vishal Asthana
Also, the OWASP Top 10 represents only a tiny fraction of application security, which also includes vulnerability management, dependency management, incident management, governance, training, and awareness, said Brian Glas, one of the OWASP 2017 project leaders and director of strategic services at nVisium.
The Top 10 covers around 20 to 25 CWEs (Common Weakness Enumerations), and there are over 700 listed, he pointed out.
"App sec is a very large onion. There are many layers to it. The idea of the Top 10 is to give you your first bite."
—Brian Glas
The OWASP Top 10 may be deficient in another way, said Mic Whitehorn-Gillam, a senior security consultant for Secure Ideas.
"It's a general guideline. It doesn't understand your business or your industry."
—Mic Whitehorn-Gillam
That's why companies need to do some level of threat modeling to figure out which vulnerabilities are most risky to their business. "For some companies, losing user data is the number one risk," Glas explained. "For others, it's brand damage."
It's beyond the scope of the OWASP Top 10 to address everything that may pose a risk to an organization, but it's still the organization's responsibility to address those vulnerabilities, Whitehorn-Gillam added.
Looking beyond the list
Does exclusion from the Top 10 mean those items should be ignored? Certainly not. In fact, the 2017 OWASP Top 10 team cautioned security practitioners: "The Top 10 covers a lot of ground, but there are many other risks you should consider and evaluate in your organization. Some of these have appeared in previous versions of the Top 10, and others have not, including new attack techniques that are being identified all the time."
Among the additional risks cited by the team are unvalidated redirects and forwards, unrestricted upload of file with dangerous type (CWE-434), user interface misrepresentation of critical information (CWE-451), inclusion of functionality from untrusted control sphere (CWE-829), and server-side request forgery (CWE-918).
Another risk cited by the team was improper control of interaction frequency (CWE-799). Software with that flaw does not properly limit the number or frequency of interactions that it has with an actor, which makes it an easy target for bot attacks, explained Ryan Barnett, principal security researcher at Akamai.
"Attackers leverage automation to achieve the vast majority of their campaigns. It is paramount that organizations have methods of identifying malicious automation from bots and attack tools and managing their impacts."
—Ryan Barnett
The team also mentioned the risk of uncontrolled resource consumption (CWE-400), which occurs when software does not properly restrict the size or number of resources requested or influenced by an actor. That flaw opens up a website to an application-based denial-of-service attack.
"Web application DoS attacks are often mistakenly thought to be addressed by network security products," observed Barnett. "The problem is that app-layer DoS attacks are different than network-level attacks, as they aren't targeting bandwidth but rather sensitive, high-load processes within applications such as search or report functions."
Also absent from the 2017 list but very commonly found in applications is cross-site request forgery (CWE-352), which forces a logged-on victim's browser to send a request to a vulnerable web application, which in turn performs the chosen action on behalf of the victim. The flaw could be used by an attacker to change a target's router settings.
"I see cross-site request forgeries often. I would say more than 50% of the web applications I test have them."
—Whitehorn-Gillam
Standards and best practices
When determining whether your policy covers all the bases that need to be addressed, it's also a good idea to check with sources of standards and best practices. For some industries, that's not an option. In healthcare, for instance, an organization needs to comply with HIPAA guidelines. In the credit card industry, compliance with PCI is mandated. And if you're doing business in the European Union, you need to meet the General Data Protection Regulation (GDPR), which took effect on May 25.
There are also many government and professional resources that can help you in formulating a policy, such as the Security Technical Implementation Guide (STIG), FIPS 200 (PDF), NIST Special Publication 800-53 R4 (PDF), and the ISO 27000 series.
By using the OWASP Top 10 as a starting point and supplementing it with additions tailored to your business's operations, you can craft a solid app security policy that reduces risk and optimizes protection.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
