The OWASP Top 10 groups common web application vulnerabilities into broad categories, helping to focus teams on key web application security activities. On the surface, this makes sense. I teach a Web Application Security class at the University of Washington incorporating the OWASP Top 10 and its framework. I also use it to categorize and group vulnerabilities that I uncover while conducting application security assessments for Security Innovation. However, the more that I use it in practice, the more its benefits as well as its shortcomings come to light.
The 2017 release candidate offers improvements, but also introduces new issues. To make the list more effective, my recommendations, in order of importance, are as follows:
- Change the wording of A4 from "Broken Access Control" to "Broken Authorization Controls" to further clarify and amplify its meaning.
- Change A7 to simply focus on logging/auditing, which is a critical security activity worthy of standing on its own.
- Remove A10 “Underprotected APIs” and add language around APIs to the other categories. Optionally change the category to backups.
COMBINED CATEGORIES
The 2017 release candidate combines the 2013 categories “A4 - Insecure Direct Object Reference” and “A7 - Missing Functional Level Access Control” into a singular category “A4 Broken Access Control”. I think this was a wise move as it created a broader and more robust category focused on authorization controls. However, I would have preferred that they also include "authorization" in the category title so as to interface better with other security frameworks. This would also be aligned with their use of "authentication" in A2 Broken Authentication and Session Management.
Why?
The new A4 Broken Access Control category is described as “restrictions on what authenticated users are allowed to do” are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts; view sensitive files; modify other users’ data; change access rights; etc." A4 assumes that the user is already authenticated and is focused on their access once authenticated. There is a concise and widely adopted word for the issue at hand - authorization. A4 isn't about Broken Access Control because it isn't concerned with "access" in the broad sense; it doesn't cover authentication, that is already covered by A2. A4 is just focused on covering authorization, and as such, should be in the name instead of the word “access.” The title should reflect the true meaning of the issue and be specific.
While this may feel like a semantics issue, I believe this wording change is important for contextualizing the conversation and providing a common understanding. Authentication and authorization have concise and specific meanings in the industry and it should be reflected in the OWASP standard.
As for the two new categories introduced this year - A7 - Insufficient Attack Protection and A10 - Underprotected APIs - these been introduced as an attempt to keep pace with the evolving web application landscape. However, I believe that the coverage of other OWASP categories renders these unnecessary.
A7- Insufficient Attack Protection
This category is defined as: "The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks."
Input validation does detect, respond, and block exploit attempts
A7 states that controls should, “[go] far beyond basic input validation and involves detecting, logging, responding, and even blocking exploit attempts." This is exactly what input validation does - It detects malicious or undesired user input, raises an error, or responds to it by removing, logging, or blocking it. If the application requests a dollar amount for a bank transfer and a user supplies a negative number, the application will recognize the malicious input and respond by blocking the transaction. Saying that input validation does not detect and respond to exploit attempts is inherently inaccurate and misleading.
Patching is covered by A9 and A5
A7 states that, "application owners also need to be able to deploy patches quickly to protect against attacks." While accurate, this overlaps with both: A9 Using Components with Known Vulnerabilities and A5 Security Misconfiguration (which includes "software should be kept up to date"). Including the issue of patching in yet another category is redundant and diminished the value of categorization.
The A7 category does not really bring anything new to the table
As mentioned previously, proper controls for validating user input to prevent A1 Injection, A2 Broken Authentication, A3 XSS, A4 Broken Authorization, A6 Sensitive Data Exposure, A8 CSRF all cover the issue of detecting user input, logging (sometimes), responding, and blocking malicious attack. Does the login page not throttle access attempts? That's an A2 or A5 issue. Is someone using SQLMap to try and break in? That's an A1 issue. Does the application need a patch? That's an A9 issue.
A7 covers devices/applications usually out of scope
If we accept, for a moment, that an Insufficient Attack Prevention category should still be adopted, then it seems the best way for an organization to address the issue is deploying IDS/IPS/WAF appliances. However, all of those measures (network hardware and infrastructure appliances) are external to and not part of the web application. While I realize that applications don’t operate in isolation, the OWASP Top 10 should just focus on the security of web applications, and not the larger infrastructure ecosystem. It's a slippery slope…
Don’t treat the symptoms, treat the root causes
A7 seems to incentivize a “toss technology at the problem” behavior. The industry has become increasingly reliant on technology that vendors over-hype and generally under-deliver on. These enterprise-ready dynamic exploit detection and mitigation solutions of questionable efficacy are a large source of revenue for a variety of companies. This isn't inherently bad, but the usage of such appliances should be carefully considered on its own merits. I have worked at large firms that chose to deploy Web Application Firewalls (WAFs) rather than actually fix the issues in their web applications. I've had conversations with application owners that have said they would not fix web app vulnerability findings because they have an IDS system in place that would catch SQL injection attempts. This is a type of moral hazard. The existence of these appliances can disincentivize mitigating underlying issues.
Beyond my OWASP Top Ten inclusion concern, the problem fundamentally stems from the trend of having traditional network security departments inherit application security responsibilities. This creates a bad habit of trying to solve problems from a network/infrastructure angle instead of addressing the root cause and securing the application itself. Because of this, I am hesitant to recommend the deployment of security appliances outright as an OWASP Top 10 category as it incentivizes companies to deploy a packaged solution instead of fixing the underlying issues that fall into other OWASP categories. Appliances can be useful in select scenarios and can be listed as a mitigation under one of the other categories such as A1 - Injection or A3 - XSS, but they should not be listed as a distinct category.
My recommendation is to remove the category or change the focus to logging, which allows for controls around repudiation, incident response, and auditing – and is simply an overall important security control. By doing so, it fills in a gap in the 2013 OWASP categories, making it easier for organizations to focus and implement, and would result in greater adoption and overall security.
A10 - Underprotected APIs
A10 states "modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc). These APIs are often unprotected and contain numerous vulnerabilities."
A poorly secured API is simply a poorly secured GUI-less web application. An increasing number of web applications are just clients that run in the browser and access an API. Drawing a distinction between APIs and web applications just muddles the issue and makes the OWASP Top 10 less future-proof. How do I categorize a SQL Injection vulnerability through an API? Is it an A1 vulnerability or an A10 vulnerability?
With the proposed 2017 framework it would be both. Categorizing the issue as A1 makes sense, but categorizing it as A10 adds little to no value. The impact, mitigation, and priority is tied to the A1 category anyway. The A10 category essentially says it’s an API – making the whole system seem unnecessarily messy and redundant. Other examples:
- If the API is unprotected, then that is either an A2 - Authentication issue, or an A4 - Authorization issue (note how well the word authorization works in this context)
- If the API contains vulnerabilities such as known vulnerable software, then that is covered by A9
- If the API exposes sensitive data, then that is covered by A6
- If the APIs are vulnerable to injection, then that is covered by A1
There is no need to make this its own category; instead, add API-related language to other requirements so application owners understand that these issues apply to APIs as well as rich web applications.
A possible category to replace the proposed A10, while a little out of left field, would be “Insecure or Inadequate Backup and Recovery.” Too often, applications don't implement sufficient backup or recovery mechanisms. Part of the CIA triad is Availability and it is a neglected aspect of security. Having robust backups of information is important to the fault tolerance of the application. What makes backups an interesting problem is that the threat scenario doesn't even require a traditional attacker. A hapless admin could wipe out a database or source code and in an instant, millions of dollars of IP or data could be lost. These types of issues don't make the news often because they tend to be categorized as embarrassing mistakes instead of incidents perpetrated by the hooded hacker or evil nation state. Nonetheless as web applications process and store more and more of our personal data, it is more important than ever that information is kept secure through a robust backup and recovery policy.
The OWASP Top Ten impacts every development team role, from architects that need to choose secure design components to mitigate OWASP Top Ten vulnerabilities; to developers that need to code defensively to avoid them; to testers that need to make sure no OWASP Top Ten vulnerabilities exist for security and compliance purposes. Check out a few of our free OWASP resources for you and your team:
