How to Avoid the OWASP Top 10 List of Software Vulnerabilities and Risks

The Open Web Application Security Project (OWASP) is a non-profit organization that works to improve the security of software applications with tools and resources, education, and training. It’s entirely community driven with hundreds of local chapters internationally and tens of thousands of members. Moreover, the OWASP Top 10 categories, which were first launched in 2003, list the most critical vulnerabilities in web applications. Since then, OWASP has launched a new version every four years, the latest of which was released in September 2021.

In this article, we’ll go over what changed in the OWASP Top 10 2021 risk categories and discuss the new vulnerability entries. We’ll also dive into the more dangerous and exploitable vulnerabilities from the new list and look at what defenses can be implemented to avoid them.

In with the new

Figure 1. Changes between the 2017 and 2021 OWASP Top 10

From the mapping in Figure 1, we can see that there were some major changes in 2021, including the top categories. Web, cloud, and browser technologies have advanced since 2017. Browsers have grown smarter and can differentiate the legitimate use of an application from a malicious one. In addition, new web frameworks and libraries such as Django, Angular, React, Node, and more now have built-in defense mechanisms to stop attacks such as Cross-site Scripting (XSS), Unvalidated Redirects and Forwards, Cross-site Request Forgery (CSRF), and SQL Injections. As a result, these vulnerabilities have fallen down the list or been removed due to reduced occurrences and impact.

With the advancement of technologies, attack surfaces have evolved over time. While it’s now significantly easier to manage and access data, it’s dangerous in the wrong hands. In recent years, numerous high-profile cyber attacks have resulted in the exposure of sensitive data. For example, in 2017, a credit card institution reported a data breach that resulted in data being stolen from 143 million people, including birth dates, social security numbers, addresses, and other private information. Not long after, an international hotel organization disclosed that hackers accessed its servers and stole the data of roughly 500 million customers. In both cases, the organizations failed to implement, test, and secure the technical safeguards, such as encryption, authentication, and firewalls. With these issues more prevalent, Broken Access Control and Cryptographic Failures have moved to the top and become the main focus.

Each category is ranked based on frequency and impact on businesses in recent years. Companies beginning their security journey can benefit from adopting this document and its proposed safeguards to ensure that their web applications are protected.

A closer look

Let’s take a look at the top 10 risks in 2021.

​1. A01:2021 – Broken Access Control

Broken Access Control moved from the fifth position to the first, the most critical web application security risk category. As the results from contributed data indicate that 94% of applications were tested for some kind of broken access control. Cloud computing and API usage contributed to the rise in this category, but these issues are also not easy to detect with available scanners. This makes it harder for penetration testers and bug bounty hunters to discover, and developers to avoid, these risks while implementing and following secure coding standards.

2. A02:2021 – Cryptographic Failures (Renamed) 

Cryptographic Failures, previously known as Sensitive Data Exposure, climbs one position from the 2017 edition. Previously, this category was a broad symptom rather than focused on the root cause. As a result, the renewed focus is on failures related to cryptography which then lead to private information disclosure or system compromise. This involves anything from hard-coded credentials to using weak cryptography (or none at all) and not properly defending sensitive data.

3. A03:2021 – InjectionInjection drops from the first position to the third as new frameworks and languages now come with default protection against injections. Additionally, developers and engineers have adapted secure code practices as the industry has come to acknowledge the impact of these attacks. Furthermore, it’s a broad category that includes many types of injections: LDAP, OGNL, OS command, SQL, and XML.According to the research, 94% of applications were tested for some sort of injection attack.
4. A04:2021 – Insecure Design (New)Insecure Design is a new category that focuses on software design and implementation flaws, and is found in the fourth spot of the OWASP Top 10. Increasing discussions about DevSecOps, shifting security left, and secure development in the community have highlighted the importance of secure design patterns for taking this process to the next level. According to the new Top 10 research, insecure design cannot be fixed by perfect implementation and, by definition, the required security controls were never implemented to defend against specific attacks. For this reason, we need to start from the left, which means making sure that security best practices are followed and that applications are built secure from the beginning.
5. A05:2021 – Security Misconfiguration 

Security Misconfiguration jumps one position to fifth, combined with XML External Entities from 2017. According to the research, 90% of applications were tested for some sort of misconfiguration, and with the shift in cloud computing and highly configurable systems, it’s not surprising this category has moved up. As more organizations adapt to cloud computing and container technologies, misconfiguration has become a common threat, especially when engineers don’t change default configurations and settings. And, according to IBM’s X-Force report, by implementing proper security configuration across applications, two-thirds of cloud environment breaches could be avoided.

6. A06:2021 – Vulnerable and Outdated ComponentsThis category was previously known as Using Components with Known Vulnerabilities, and it climbs from the ninth to the sixth position. Many applications these days use open-source libraries and components that are not tested and verified, and they often contain malicious code supplied by attackers for malware injection. These components are usually embedded into systems during the development process and are rarely updated or verified against known vulnerabilities. With the help of early verification processes and tools such as Software Composition Analysis (SCA), these types of vulnerabilities can be mitigated. SCAs identify and list all parts and components along with their versions, and also check for each outdated and vulnerable library that may introduce threats to the application.
7. A07:2021 – Identification and Authentication Failures (Renamed)This category has been renamed and slides down the list from the second position. Authentication failures occur when applications are implemented incorrectly. Specifically, functions related to authentication and session management can lead to the compromisation of passwords, tokens, keywords, and sessions when not implemented correctly; however, frameworks available today are reducing the occurrence of these issues and making them easier to deal with.
8. A08:2021 – Software and Data Integrity Failures (New) A new category in 2021, combined with Insecure Deserialization, focuses on poor integrity verification and standards, on either software updates, critical data, or CI/CD pipelines.According to the current research, this category is weighted with the highest impacts from Common Vulnerability Scoring System (CVSS) through the data analyzed.
9. A09:2021 Security Logging and Monitoring Failures (Renamed)After receiving a lot of criticism in 2017, this category made it to 2021 and moved up to the ninth position. It was previously called Insufficient Logging and Monitoring, but the renewed focus includes more logging failures. According to the OWASP report, testing these types of issues is challenging and information about them in public vulnerability databases is scarce; however, proper logging and monitoring can be very effective for accountability, visibility, and forensics.
10. A10:2021 – Server-Side Request Forgery (SSRF) (New)Another new category, Server-Side Request Forgery, was added based on community surveys.According to OWASP research, the incident rate for this vulnerability is quite low; however, the ratings for Exploit and Impact Potential are above average. The main focus of this category is to gain attention and to spread awareness, and with only a few entries available in security vulnerability databases, this can be bundled into a large category in the next edition

Best practices and testing

Let’s first talk about the shift-left approach. Shifting left means moving security earlier in the development lifecycle. A traditional development cycle involves different phases, such as planning, designing, developing, building, and testing — where security was often done last before deployment. As a result, extra time was added and security wasn’t implemented correctly, which made applications vulnerable.

Moreover, it resulted in clashes between the development and security teams. Imagine a development team finishing their work on an exciting new release and eager to get it into the hands of their users. If a security team pulls the brake to address vulnerabilities and delay the release, development and security teams could end up butting heads

By shifting security left, both teams can cooperate and integrate the required processes to deliver the release on time, and securely. This is why it’s important for developers to understand secure coding standards and methods, and they should be provided with the tools to do their job securely without adding extra work.

Second, building security into applications can be tricky given that tens, hundreds, and sometimes thousands of developers write and push code into the production environment. Organizations use TLS or SSL encryption to ensure the integrity and confidentiality of their data. This applies to all external and internal services, such as application servers, load balancers, and database servers.

Furthermore, attack surfaces can be significantly reduced if organizations focus on limiting and monitoring exposed services, ports, and API endpoints. It’s also important to pay more attention to container-based images and the system on which its instances are running.

Last but not least, let’s look at some of the testing methodologies and verification procedures.

Static Application Security Analysis (SAST) – This is a white box testing method and is also known as “security code review.” It examines the code to identify software vulnerabilities and weaknesses like SQL injection, hard-coded credentials, and unsafe coding practices. This is one of the best and most effective ways to detect security flaws in code, and organizations can benefit from having at least one static analysis tool integrated into their pipeline. OWASP has published a list of open-source tools to help with static code analysis.

Dynamic Application Security Analysis (DAST) – Unlike SAST, this is a black-box testing method that examines an application when it’s running to find vulnerabilities. It also involves running automated tests or scans to check for common security vulnerabilities and weaknesses such as SQL injection, Cross-site Scripting (XSS), Unvalidated Redirects, and Cross-Site Request Forgery (CSRF).

Software Composition Analysis (SCA) – Open-source tools and libraries have gotten so much traction these days that most organizations use these dependencies and libraries. Some of them even get integrated into their applications without being tested properly. But tools like Software Composition Analysis (SCA) can help find the publicly disclosed vulnerabilities contained within those dependencies. OWASP has published an open-source OWASP Dependency-Check tool to help with SCA analysis.

Final thoughts

In summation, OWASP provides developers and security professionals insight into the most prevalent security risks so they can incorporate the report’s recommendations and findings into their security practices to help minimize the occurrence of these risks in development. And while building security isn’t easy, it doesn’t have to be complicated either. The right approach followed at the right time can go a long way. Testing and verification procedures are also important as they play a significant role in securing applications. Learn more about the OWASP foundation, its tools, and other resources at the OWASP Foundation.