OWASP top 10 2021: what’s new and changed

A01 – Broken Access Control replaces A3 – Injection

The first thing to note, Injection has been knocked off its top spot for the first time since 2010, in its place comes Broken Access Control, which if you recall from 2017 was a new category created through the merging of two other categories from 2013, namely Insecure direct object references and Missing function level access control. Included in the new A03:2021 – Injection category is the A07:2021-Cross Site Scripting (XSS) category.

 

What is Broken Access Control?

 

Broken Access Control has been identified as the most critical web application security flaw by OWASP effecting DevOps and developers. With OWASP attributing this to insufficient secure coding practices by developers and deploying applications which evolve over time as they move through the SDLC cycle to release. Therefore, the challenge for developers and DevOps is ensuring reliable access controls exist in the application which can be difficult to identify as the web application changes over time.

Access controls also known as authorization is the security constraints applied so unauthorized access is prevented and adversaries can’t locate other exploitable vulnerabilities found in the code. Insufficient access controls can lead to hackers gaining access to resources such as critical data and launching attacks on other areas of your infrastructure and disrupting your business operations.

 

How to prevent Access Control flaws

 

The code that implements the access control policy needs to be scanned and security tested continuously throughout the SDLC and before deployment. The code needs to be built in such way maximum security measures are applied for existing and future development projects. A detailed code review should be performed to ensure secure code implementation in your web application and understood by your development team. Secure code training can provide interactive training specifically designed for Developers to understand and explore how to write clean, readable, defensive code. In addition, penetration testing can be useful for one off application deployment checking to easily identify problems in the access control scheme and implementing patching to ensure this issue doesn’t become an operational headache however this can soak up time and budget leading you open to hacking as they hunt your applications to break in.

In-house developers: Static Application Security Testing can be implemented early in the SDLC by performing deep and extensive security analysis of the applications source code at the start. Reducing risk of access controls being attacked to ensure confidence the application contains no faulty code later. 

In-house development and third-party apps: Dynamic Application Security Testing can be applied to your live web applications whether they’ve been developed in house or by a web application agency. Carrying out a comprehensive whitebox security test (like a hacker would). Highlighting post production security flaws in live web services, reducing risk of live applications containing access control issues to fast track remediation activities.

DevSecOps: It’s even more important for security teams to have a catalogue of your web application blueprint (both known and unknown) to be able to perform regular tests to find issues which can lead to cyber-attacks. Once these are identified for your organization, risk scoring can be applied to all internet facing applications according to how they perform against the seven common web app attack vectors to prioritize remediation and reduce your external attack surface.

 

What is Cryptographic Failure?

 

In addition to the top spot, No.2 changes from Broken Authentication – now called Identification and Authentication Failures to Cryptographic Failures, the renamed Sensitive Data Exposure category. With data breaches on the rise and attackers looking for quick gains to access critical data, with security researchers predicting 40 billion records will be compromised by the end of 2021 as a result of issues including identification and authentication flaws.

With attackers evolving their techniques its critical for security teams to assess the potential open doors which would let them into your web applications. Adversaries today are using more sophisticated methods that evade traditional perimeter security solutions hence why cryptographic failures are so high up the OWASP Top 10 list. With attackers looking for notable CWE vulnerabilities including CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy.

 

How to prevent Cryptographic Failure

 

Discovery: The first thing is to determine the data you have and how it needs protecting i.e passwords, PII information of your stakeholders and IP information that requires extra protection and could potentially lead to data protection fines for failure to implement for example EU’s General Data Protection Regulation (GDPR), or other compliance regulations to maintain maximum data sovereignty.

Continuous and automated penetration testing can assist in identifying CWE’s which could lead to cryptographic failure and SQL injection and XSS attacks. When development speed and scale is business critical, our hybrid application security testing solution combines automated scanning and experienced pen testers to provide the most accurate and complete assessment of software vulnerabilities from the OWASP top 10 and CVE’s in the infrastructure layer to secure your critical data at all times without the need to overstretch existing security resource.

Other OWASP web application flaws identified

Moving up and down the list:

 

Other categories from 2017 get a rename,A09- Using Components with Known Vulnerabilities is now Vulnerable and Outdated components, moving up the top 10 from A09 to A06. And A10 – Insufficient Logging and Monitoring, moves to A09 and is now called Security Logging and Monitoring Failures. A04-XML External Entities (XXE) vanishes as a separate category and is now included within the 2017 A06 Security Misconfiguration in the 2021 A05 – Security Misconfiguration Category.

 

New entries:

 

On the new category front, we see the introduction of A04-2021 – Insecure Design, with OWASP describing this as focusing on risks related to design and architectural flaws, with a call for more use of threat modelling, secure design patterns, and reference architectures – this category will pose challenges for automated tools to detect accurately, much like A09:2021 Security Logging and Monitoring Failures will continue to do as these categories relate to process driven activities.

The next new category is A08:2021-Software and Data Integrity Failures – of which the A08:2017-Insecure Deserialization category is now a part of. OWASP describe this category as Software and data integrity failures related to code and infrastructure that does not protect against integrity violations, including the aforementioned Deserialization, but also the use of plugins, resources and libraries from untrusted sources.

Our final new category for 2021 is A10:2021 – Server-Side Request Forgery (SSRF). OWASP’s description of this says SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. However, it should be noted this has a low incidence of CWE’s and so may only stay for the 2021 update, being moved into a broader category either as we get closer to release or in the future (OWASP Top 10 2025!)

 

What does this all mean for Application Development, DevSecOps and the state of Application Security?

 

Firstly, Application Security is clearly still an issue, with this list highlighting the importance of securing applications through recommended DevSecOps processes and the correct application security testing tooling. The publication of this list may help security teams push the need for adequate budgets to push this up the boardroom agenda. Despite its drop in position injections continue to occur in over 90% of the sample applications used to compile this year’s list. With the addition of A04:2021 – Insecure Design efforts shift to looking at the entire Application lifecycle, to ensure organizations are building security into their CI/CD pipeline in a continuous and automated fashion to boost security effectiveness.

Secondly, it will be tricky for any vendors to provide full coverage of the 2021 OWASP Top 10 because of the complexity in an application ecosystem. OWASP themselves say this regarding this list: “We would encourage anyone wanting to adopt an application security standard to use the OWASP Application Security Verification Standard (ASVS), as it’s designed to be verifiable and tested, and can be used in all parts of a secure development lifecycle.”

The ASVS is the only acceptable choice for tool vendors. There’s no single tool that can comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks, with reference to A04:2021-Insecure Design. OWASP discourages any claims of full coverage of the OWASP Top 10, because it’s simply untrue.

 

What’s next?

 

Watch this space as we explore the new Top 10 list in more detail in further blog posts, discussing what they are and the impact to DevSecOps in general and how this impacts the different stages of the SDLC. We will also delve into the ASVS mentioned by OWASP as a more appropriate standard to follow and look at how application security tools can help towards achieving those standards. However, don’t delay the implementation of an application security program for your organization. Hackers may already be looking for the next opportunity to launch an attack.