The OWASP Top 10 refers to the top web application security risks, as published by the Open Web Application Security Project (OWASP). OWASP helps organizations get started with the secure development of web applications. The OWASP project started in 2001, with community-led OWASP Foundation, which was registered in 2004 in the United States. In addition, a nonprofit entity is registered in Belgium: OWASP Europe VZW.
The OWASP team published their first Top Ten security risks list in 2003, documenting the critical risks facing organizations and their web applications. OWASP periodically updates the list, informed by the survey data the organization collects.
This glossary post provides an introduction to the OWASP Top 10, including how it is used, and a breakdown of each of the ten most recent security risk entries from the list.
Many groups adopt the OWASP Top Ten as the basis for their web application security strategy, aiming to assess against and address the listed items as their priorities. Some testing systems and implementation tools also incorporate The OWASP Top Ten.
The OWASP Top Ten security vulnerabilities list has evolved over time. Some entries have been combined with other areas as technology and architectures have evolved and as some threats have matured.
While the OWASP Top Ten aims to improve the secure development of web applications, the same criteria are often used for evaluating the security hygiene of any web application or critical software, even off-the-shelf solutions that are either hosted internally or available via the cloud.
Below are the ten top ten security risks comprising the OWASP Top 10, as published in September 2021. We have provided a brief description of each entry, and why it is important.
The first security risk entry from the OWASP 10 focuses on the approach to access control within an application. This entry moved up to #1, from #5 in the previous OWASP list. According to OWASP, broken access control was present in 3.81% of tested applications.
Broken access control involves unwanted and/or unauthorized access. This means access that occurs outside of intended permissions or entitlements.
Broken access control may mean a user is able to gain admin rights and potentially launch a vertical or horizontal privilege escalation attack. This excessive access can lead to data breaches, data manipulation, planting of malware, reconnaissance, lateral movement by a threat actor, and more.
Access control--especially privileged access controls--is integral to the integrity of applications, systems, and data. Proper access controls include implementing the principle of least privilege (PolP) in the permissions model, and enforcing zero trust for all page accesses. Zero trust in this instance entails verifying access is appropriate and preventing manipulation of requests from gaining access to data. Do not assume the URL alone indicates protection.
Broken access control links to 34 Common Weakness Enumerations (CWEs) that document specific scenarios relating to broken access controls.
Encryption tends to focus on two key scenarios: at rest and in transit. In both of these scenarios, poor implementations may result in the exposure of sensitive data.
The CWEs linked by this (29 in total) focus on ensuring sufficient encryption to protect data being processed. With data protection legislation continuing to expand and pose more significant penalties, this entry will increase in importance.
Injection refers to a malicious user adding to or substituting the commands for data access within a URL to bypass the application-level controls for data access. This entry occupied the top spot in the 2017 version of the OWASP Top Ten. This doesn’t diminish the security importance of injection attacks, but it does highlight that more applications are addressing the concern.
This item different from most others since it focuses on the design versus the implementation. A perfectly implemented bad design is still a bad design. This highlights the need to bake security into the application architecture, and it is commonly referred to as secure by design. It’s a seemingly simple and innocuous change in wording from “how do we develop the application and secure it” to “how do we securely develop the application.”
There are 40 CWEs linked to Insecure Design, which indicates how poorly organizations are doing this one today.
Misconfiguration is, from an implementation and operation perspective, one of the most common issues reported in the press, particularly with regard to cloud breaches. This attack vector can easily be avoided if you know your environment is misconfigured. The first of these findings is entirely implementation-driven. Even the most secure applications in the world hold the potential to be misconfigured by users, opening them up for abuse by threat actors. Common elements here include default passwords and unnecessary superuser permissions.
There are 20 CWEs linked to this recommendation, which can be taken to indicate that the scope isn’t broad. But keep in mind, the impacts can be dramatic.
This item relates to software components used to develop and deliver applications and services that are often overlooked as a potential route for exploitation. This vulnerable and outdated components represents a particularly critical in cloud environments because those components are more exposed to attack than in on-premise scenarios. Ensuring that components are actively updated to the latest supported components is imperative. Security-conscious organizations should query their vendors on the techniques in place to safeguard your use of their solutions.
This category is unusual among the OWASP Top Ten because it has no CWEs mapped to it. The vulnerable and outdated components are an ever-evolving list, making it difficult to track all potential candidates, and even harder to assess complete coverage.
Good vulnerability management software should give you a view across all the installed elements in the environment; it should also allow you to track them as a part of your assessment strategy. An active patch management and update program will ensure software in the environment is up to date and as secure as possible.
In this context, failures of identification and authentication primarily relate to failure to prevent identification and authentication attacks. Identity and authentication-based attacks include credential stuffing, brute-force password attacks, and session hijacking. While weak/well-known/default/hardcoded passwords and poor password recovery processes include some of the common risks that allow password attacks to succeed. Authenticating a user's identity is the primary mechanism for granting access to systems in the cloud, regardless of how that authentication is achieved (i.e., username/password, biometrics, smart cards).
Today, it’s clear that single-factor mechanisms for authentication (for individual accounts) should be deprecated. That said, most authentication falls back to a password. So, while biometrics and newer alternative approaches grow more popular, organizations must not forget about good password practices and good password hygiene.
In total, 22 CWEs cover the proper ways to secure identification and authorization, particularly when developing software. This is equally applicable in all aspects of authentication within your environment, from end users to support staff.
Software integrity has reared its head as a significant problem in recent years. Threat actors are targeting the software vendors not only to directly exploit the vendors, but to gain access to their customers. Major breaches (SolarWinds Orion, etc.) originated in the update processes of critical software. Such attacks are referred to as supply-chain attacks.
From a software vendor perspective, it’s important to ensure the components managed in OWASP A06 are from trusted sources, appropriately signed, and have not been tampered with. From a software user’s perspective, they want to validate that software updates follow the same management and source verification process.
Within critical applications, data integrity is vitally important because the data is often stored outside of the application itself, within database servers managed by the end users in cloud services. Data can be manipulated to affect the operation of software and disrupt or misdirect the organization's activity. The potential impact of data manipulation could exceed the impact of a software vulnerability. With that aside, ensure data integrity requirements are appropriate for the data in question.
Visibility is essential in cybersecurity, both for prevention and defense. Security failures (breaches, etc.) due to insufficient logging and monitoring of security events have propelled this item up the Top Ten by one place for the 2021 list.
Logging key activities, such as authentication into and out of a system, as well as changes to configuration, including access permissions, is essential to distinguish between legitimate activity and malicious operations.
In addition to logging, we need event monitoring, which, ideally, is correlated to approved activity. For example, missing change management tickets ensure that the malicious activities present a sufficient signal to trigger an active response.
While the OWASP Top Ten focuses on software development, this item depends on external log storage and assessment to mitigate the associated threats. Keep in mind, logging for logging’s sake doesn’t improve security; it renders it less effective because there’s more noise in the system. Like many security aspects, appropriate controls maintain a vital balance.
The small number (4) of associated CWEs for this entry belies the importance and reach of this risk.
Server-Side Request Forgery (SSRF) is facilitated by the increase in functionality offered to users and enabled by some offerings. This is more likely to be relevant in a cloud scenario because cloud-based services commonly rely on other cloud-based services to produce a final offering. Applications and supporting services often require users to provide the URLs for those other services, while interacting with the primary application via some form of configuration. This is typically GUI or a file-based configuration.
Someone gaining access to the URL configuration elements could misuse the shared URLs to attack other systems, or discover aspects of the systems sitting behind the application itself. The threat actor can do this by trying URLs with address and port combinations to find open ports and services.
While software vendors need to implement mechanisms to prevent misuse, it’s another area where appropriate permissions (least privilege) can provide a significant protective benefit. This is illustrated in the below figure: