OWASP Updates the Top 10 Web Application Security Risks
Tags: webdev, informationsecurity, programming, hacking
Published: 2021-10-26 21:19:10

---
title: OWASP Updates the Top 10 Web Application Security Risks
published: true
date: 2021-10-26 16:06:29 UTC
tags: webdevelopment,informationsecurity,programming,hacking
canonical_url: https://blog.shiftleft.io/owasp-updates-the-top-10-web-application-security-risks-4cb9901fee0a
---

### OWASP Top Ten updates: what changed?

#### OWASP updates the top 10 web application security risks

![](https://cdn-images-1.medium.com/max/1024/0*MR9KPYgzCjFino0E)<figcaption>Photo by <a href="https://unsplash.com/@homajob?utm_source=medium&amp;utm_medium=referral">Scott Graham</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption>

The Open Web Application Security Project, or [OWASP](https://owasp.org/), is a non-profit organization dedicated to improving software security. They offer various services to help developers improve, including tools, social events, and educational resources. They also offer useful guides including the recently updated _OWASP Top 10 Web Application Security Risks_.

But first, how does OWASP determine the top ten web application security risks? OWASP creates their web application risk list by using both data analysis and industry surveys. They use applications donated specifically for analysis to determine the data-driven portion of the list. Two of the top ten risks are decided by survey responses returned by members of the community. This process allows developers to highlight risks they often encounter that may not be reflected in the analyzed data.

### What Are the OWASP Top 10 Web Application Security Risks?

The OWASP Top 10 Web Application Security Risks list has recently been updated. By comparing it to the previous version, released in 2017, developers can see longstanding problems plaguing software development along with newly recognized issues.

The lists includes:

![](https://cdn-images-1.medium.com/max/596/1*F7GslTA82hqwKUjd28p7IQ.png)

### Breaking Down the Risks: from 2017 to 2021

Now let’s take a closer look at what has changed from the 2017 OWASP top ten to the 2021 OWASP top ten!

#### [Injection](https://blog.shiftleft.io/api-security-101-injection-a7feea1d4fd)

Injection risks describe the insertion of untrusted data to an interpreter as part of a command or query. This category includes SQL, NoSQL, [OS](https://www.shiftleft.io/blog/what-are-command-injection-vulnerabilities-08-10-2021/), and LDAP injections among others. Malicious injections seek to subvert interpreters into executing harmful commands or revealing sensitive data. This risk category now includes _cross-site scripting,_ which had its own entry in the 2017 list. One way to [prevent injection vulnerabilities](https://infosecwriteups.com/they-are-all-injection-vulnerabilities-ddcef366e39e) is by keeping data separate from queries and commands.

#### [Broken Authentication](https://blog.shiftleft.io/api-security-101-broken-user-authentication-1df2ef3420d8)

Broken authentication, as the name suggests, occurs [when poorly implemented session management creates opportunities for attackers to take over user accounts](https://blog.shiftleft.io/api-security-101-broken-user-authentication-1df2ef3420d8). Threat actors who break authentication or other session management functions may gain access to passwords, keys, or session tokens. They may also be able to seize legitimate user identities and exploit those as well. This risk category became part of _Identification and Authentication Failures_ in the 2021 version of the OWASP list.

#### [Sensitive Data Exposure](https://blog.shiftleft.io/api-security-101-excessive-data-exposure-a730d351fbae)

Sensitive data can be exposed by applications or APIs that do not have adequate built-in protections. For strong security, it is important to provide protective measures for data in transit or at rest. Sensitive data is a valuable commodity for threat actors, making data security particularly important. Stolen data may be monetized through committing fraud, blackmail, identity-related crimes, or sold on the dark web. In the 2021 list this category was merged into _cryptographic failures_.

#### [XML External Entities (XXE)](https://blog.shiftleft.io/intro-to-xxe-vulnerabilities-appsec-simplified-80be40102815)

XML Eternal Entities (XXE) risks describe vulnerabilities that allow the exploitation of XML processors to commit DDOS attacks or perform other malicious activity. Deprecated or misconfigured XML processors can also be tricked into [revealing internal files, file shares, performing internal port scanning, and remote code execution.](https://www.shiftleft.io/blog/detecting-and-exploiting-xxe-appsec-simplified-01-29-2021/) Since XXE attacks rely on Document Type Definitions (DTDs) being enabled, [disabling](https://www.shiftleft.io/blog/preventing-xxe-in-java-applications-02-12-2021/) them where possible is recommended. If disabling DTDs is not an option, OWASP has an [XXE Prevention Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md) that offers alternative security steps. In the 2021 list this category was merged into _security misconfiguration_.

#### [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)

Broken access control is a broad risk category that generally describes vulnerabilities that allow attackers to circumvent permission restrictions. Examples include elevation of privilege attacks, [bypassing access control checks](https://www.shiftleft.io/blog/api-security-101-broken-function-level-authorization-07-27-2021/), and using [insecure direct object references](https://vickieli.dev/info%20leak/intro-to-idor/), among others. Attackers who exploit broken access control measures may steal private data, hijack user accounts, modify user rights, or perform other malicious activity.

#### [Security Misconfiguration](https://www.shiftleft.io/blog/api-security-101-security-misconfiguration-08-17-2021/)

Security misconfigurations are the most common security risk affecting web applications. They are often the result of:

- Relying on default accounts, passwords, or configurations
- Leaving unnecessary ports, accounts, services, or other features, enabled
- Incomplete or outdated security configurations
- Out of date or unpatched software
- [Misconfigured HTTP headers](https://developer.okta.com/blog/2021/10/18/security-headers-best-practices)
- Error messages that reveal too much about the underlying system

Preventing security misconfigurations relies on establishing a repeatable and effective procedure for hardening systems, software, and processes.

#### [Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)

Using unpatched, outdated, or vulnerable components in an app undermines its security and may expose it to various cyber attacks. These risks arise from vulnerabilities in libraries, frameworks, and various modules which gain the same permissions as the app when executed. [Disabling unnecessary dependencies, using only trusted components](https://www.shiftleft.io/intelligent-software-composition-analysis/) and following a trusted patch management process can reduce exposure to these risks. This category was named u_sing components with known vulnerabilities_ in the 2017 list.

#### [Security Logging and Monitoring Failures](https://www.shiftleft.io/blog/api-security-101-insufficient-logging-and-monitoring-09-28-2021/)

Identify a breach quickly is key to minimizing damage, but insufficient logging and monitoring hinder threat detection efforts. Studies indicate the average breach takes [228](https://www.varonis.com/blog/data-breach-statistics/) days to detect, giving attackers ample time to wreak havoc. Apps can mitigate these risks by ensuring security events are logged error/warning messages are clear and concise, and high-value transactions have audit trails. This category was named _insufficient logging & monitoring_ in 2017.

#### [Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)

Cryptographic failures are when sensitive data or secrets are insufficiently protected. Sensitive data needs to be encrypted or stored as a hash while in transit or at rest. For instance, passwords need to be stored as a hash instead of as plain text, and sensitive personal information should only be transmitted via HTTPS. Failing to protect sensitive data may result in attackers committing fraud, blackmail, identity theft, or other information-based crimes. Companies may face severe penalties from exposing sensitive data due to violating privacy legislation like the EU’s GDPR or the financial industry’s PCI-DSS. These risks include those listed in the _sensitive data exposure_ category from the 2017 list.

#### [Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/)

This is a new category that covers risk exposures due to “missing or ineffective control design.” It differs from insecure implementation in that flawed design can never be perfectly implemented, while perfect design can be implemented poorly. Flawed designs may be missing necessary security controls, have dependencies with known vulnerabilities, or be fundamentally insecure for other reasons. These risks can be mitigated through using secure design patterns and principles and carrying out extensive threat modelling and testing.

#### [Software Data and Integrity Failures](https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/)

This new risk category broadly encompasses failures related to faulty assumptions about software updates, critical data, and CI/CD pipelines. This includes applications that rely on insecure components or services like libraries, plugins, or content delivery networks. It also encompasses [_insecure deserialization_](https://medium.com/swlh/hacking-java-deserialization-7625c8450334) (from 2017)_,_ which occurs when serialized data from a file, network socket, or stream is insecurely transformed into an object. These risks can be mitigated by only using trusted repositories, or [verifying dependencies through extensive security testing](https://www.shiftleft.io/intelligent-software-composition-analysis/).

#### [Server Side Request Forgery](https://vickieli.dev/ssrf/intro-to-ssrf/)

This new risk category involves web applications that do not check or validate user-supplied URLs before fetching remote resources. Attackers can exploit these vulnerable applications to send crafted requests to malicious URLs, thereby bypassing firewalls, VPNs or access control lists. These risks can be mitigated through network segmentation, disabling HTTP redirection, sanitizing user input, and other measures.

### Benefits of using the OWASP Top 10 Web Application Security Risks List

The OWASP Top 10 Web Application Security Risks list is a handy reference for guiding developers through common issues that make code insecure. As devs familiarize themselves with detecting and addressing these risks their apps will benefit by becoming more resilient to cyber threats. Appsec folks can also benefit by taking these top risks into consideration when creating security processes. Organizations can use the list to proactively integrate procedures that identify and remediate these risks throughout the software development lifecycle.

For more information on ways to avoid the OWASP web app risks and other code security issues, visit [ShiftLeft.io](https://www.shiftleft.io/shiftleft-core/). ShiftLeft is dedicated to promoting secure code practices and offers several tools and resources to help developers write stronger, more resilient apps.

* * *