The Open Web Application Security Project (OWASP) is a nonprofit foundation dedicated to promoting best practices, methodologies, and tools for developing secure and reliable applications. In early 2003, they began publishing a list of the top 10 most common application vulnerabilities based on real incidents and community evaluation.
According to the 2021 version of the list, risks like insecure design, Cross-Site Server Forgery (CSSF), and software and data integrity failures are on the rise. These issues can seriously compromise application security.
Keep reading for a comprehensive explanation of what’s new in the OWASP Top 10 for 2021, along with an introduction to some mitigation techniques you can use to protect against these vulnerabilities.
What Is the OWASP Top 10 and Why Is It Valuable to Security Teams?
Simply put, the OWASP Top 10 is a list of the top ten security risks that web applications face. It’s updated regularly to reflect the current status of web application security and related fields. Crucially, OWASP sources most of their recommendations from factual events and CVEs which they reference on their website.
The list is critical for security teams, as it enables them to correlate real security events with their own security policies. For example, they can research past incidents and compile a checklist that they can use to assess how prepared they are to guard against those risks.
Let’s take a look at the new categories of risks that are part of the OWASP Top 10:2021.
What Are the New Categories in the OWASP Top 10 for 2021?
According to the official OWASP Top 10:2021, a few issues have changed in rank and three new categories have been added, as you can see below:
A04:2021 – Insecure Design
This is a new category that simply stresses the fact that failing to integrate secure software design early in the development cycle often results in insecure applications.
Common mitigation techniques rely on shift-left security as well as ensuring that security considerations are baked into the software from the start. Development teams should start thinking about potential threat actors as early as possible, and they might also want to integrate threat modeling into their processes so that they can be better prepared for any scenario.
This means that the development and security teams should brainstorm about how the system could be exploited before attackers are able to exploit the rules of the application and cause real production issues. That way, they can integrate security controls and fallbacks in case those incidents occur.
Notable CVEs related to this category include CWE-183: Permissive List of Allowed Inputs and CWE-209: Generation of Error Message Containing Sensitive Information.
A08:2021 – Software and Data Integrity Failures
This is another new category for 2021, and it ranks 8th on the list. This category includes security risks related to consuming fake or vulnerable dependencies listed in remote registries or in untrusted locations. (For example, many NPM packages are exploited this way.) This may cause your application to stop downloading and run unsafe dependencies from public repositories because their initial source was modified.
One obvious solution is to ensure that you include integrity checks when you download dependencies. You could also use private registries as a way to ensure that you only download from trusted sources. Scanning dependencies as part of your CI/CD pipeline can help expose security issues early by notifying the code owners of security risks before the final deployment.
A10:2021 – Server-Side Request Forgery
This is a new category that occupies the 10th spot on the list. This risk includes attacks that force the server to issue HTTP requests on its behalf – hence the name server-side forgery.
It’s no surprise that this kind of attack surfaces when you supply requests that trigger server hooks or events that can perform some sort of exfiltration or data manipulation. For example, an attacker might send a carefully crafted POST request that triggers an event to send emails to a particular address or a request to a particular server that is not in the application server's known server list. This increases the risk of exposing sensitive information or performing unintended actions.
To prevent this kind of attack, you should always have a list of allowed domains with strict verification (possibly with SSL pinning or outbound firewall rules) and disallow any deviations from these patterns.
How Have Other Categories Evolved Since 2017?
The ranking of risks on the OWASP Top 10 has changed since 2017, possibly due to the fact that attackers have found new ways to exploit applications, and also because organizations have become more aware of these risks. Lets take a look at a few of them.
A01:2021 – Broken Access Control
This moved from number 5 to number 1, and it now represents the most common risk factor for web applications. It’s primarily related to attacks that allow an attacker to examine and exfiltrate sensitive information with relative ease or to access private resources by path manipulation.
Although this risk is very concerning, you can find a great deal of documentation that will tell you how to protect against it. From what I understand, the risk has risen due to a failure to set security baselines (by prohibiting access to resources by default), incorrect configurations (for example, leaking secrets in version control systems or exposing private S3 buckets), or failing to perform security audits before releases (which would include issues like vulnerable dependencies and missing test cases).
Hopefully, this list will help security professionals understand the risks of improper authorization and access control as well as help them prepare to mitigate them.
A03:2021 – Injection
This category slid from number 1 to number 3 on the list. It includes events related to Cross-Site Scripting (XSS) and SQL injection. Injection attacks are a constant threat to web applications because they can penetrate defenses quite easily and cause critical damage. Using web frameworks that sanitize parameters and protect against SQL attacks will go a long way toward preventing those kinds of issues.
This is not a bulletproof strategy, however, since a lack of sufficient technical knowledge or a failure to thoroughly test flows with unusual inputs can cause issues. My recommendation here is to try to incorporate some sort of runtime host protection that will catch and prevent unusual inputs before they get processed.
A07:2021 – Identification and Authentication Failures
This slid from the second to the seventh position, and it represents risks related to improper authentication and identification of resources. You can interpret this as relatively good news, since identification and authentication are hard to secure properly.
However, you can see that the industry is moving toward modern authentication solutions like external authentication using vendors such as OKTA or AUTH0, passwordless auth, or multi-factor auth (with the caveat that SMS multi-auth is prone to social engineering attacks).
A06:2021 – Vulnerable and Outdated Components
This category has moved up two places since the last time the OWASP list was updated, and it represents risks related to outdated components. Most of the time, outdated components are time dependencies that applications need as part of their deployment or the runtime binary distribution.
If you are working on large-scale projects, you might find that dependencies are updated frequently, and you have to manually upgrade them in your applications. If you use open-source projects, you can check the _.lock files (package.lock, Gemfile.lock, and so on) to see what kind of nested dependencies your project relies on.
Automated repository bots like Dependabot can help you automate this process by outlining the risks of each update. However, you should still periodically review the code to clean up any unused dependencies and be aware of the security implications of using outdated or deprecated components.
How to Get OWASP Top 10:2021 Protection
Understanding the risks outlined in the OWASP Top 10 is an excellent starting point, but you still need to understand how to put that information into practice to protect your applications. Developing secure applications is a complex task that requires you to bake effective design and security protections into your product from the very beginning of the development cycle.
Prisma Cloud gives you out-of-the-box API and workload protection, complete with customizable support for the OWASP Top 10. It can also facilitate additional security controls like vulnerability management, compliance, and runtime defense, which gives you a complete, in-depth defense platform that enables you to expose your applications to the internet with confidence.