What is OWASP Top 10?

The Open Web Application Security Project (OWASP) is an open source application security community with the goal to improve the security of software. The OWASP Top 10 is an industry standard guideline that lists the most critical application security risks to help developers better secure the applications they design and deploy.

Since security risks are constantly evolving, the OWASP Top 10 list is revised periodically to reflect these changes. In the latest version of OWASP Top 10 released in 2021, some types of vulnerabilities which no longer represent a serious threat were replaced with ones most likely to pose a significant risk.

While the OWASP Top 10 is a great place to start securing applications, it certainly should not be considered as an end goal, since some of the most-cited vulnerabilities didn’t make it into the OWASP Top 10 2021. To guard against software weakness, defenders need to look more broadly across their information-technology stack. This means IT security professionals need to focus across the entire software ecosystem and look beyond the ‘traditional’ sources of vulnerabilities.

What are the OWASP Top 10 (2021) categories?

A1: Injection

Injection flaws can be introduced whenever an untrusted data source is sent to an interpreter. Examples are often found in SQL, LDAP, XPath or NoSQL dynamic database queries with user supplied input. Attackers inject code into the user input, tricking the query interpreter into executing malicious commands.

What makes an application vulnerable to injection flaws?

• User-supplied data not being sufficiently validated.
• Dynamic queries run without enough input sanitization.
• Hostile data used within systems for malicious behavior.

What’s the impact of injection flaws?

• Compromise of the application or underlying host.
• Exposure of sensitive data.
• Loss of productivity, reputation, or revenue.

How can Fortify help with injection flaws?

• If you are a developer: Fortify detects injection flaws and provides type-specific remediation advice.
• If you are in QA or Operations: Fortify validates code at runtime for mitigating controls.
• If you are in Operations: Fortify provides runtime logging and protection for Java and .NET injection attempts.

A2: Broken authentication

Broken authentication can be introduced when managing identity or session data in stateful applications. Examples are often found when registration, credential recovery, and API pathways are vulnerable to unexpired session tokens, brute forcing, or account enumeration. Attackers assume the identity of legitimate users, taking control of accounts and compromising data, processes, or systems.

What makes an application vulnerable to broken authentication?

• Exposes, does not properly invalidate, or fails to rotate session IDs.
• Does not align password policies with standards such as NIST 800-63B.
• Lacks two-factor authentication (2FA) or permits automated attacks.

What’s the impact of broken authentication?

• User identity theft.
• Loss of user trust.
• Compromise of sensitive data.

How can Fortify help?

• If you are developer: Fortify detects and recommends remediation for broken authentication issues.
• If you are in QA or Operations: Fortify validates authentication and session management security dynamically.
• If you are in Operations: Fortify instruments runtime monitoring for Java and .NET application events.

A3: Sensitive data exposure

Sensitive data exposure issues can be introduced when applications access unencrypted data, particularly personally identifiable information (PII) and other regulated data types. Examples are often found when weak cryptographic cyphers are used in legacy applications, secure transport protocols are implemented incorrectly, or data-centric security is not in use. Attackers gain access to sensitive user data that gives them control in real life.

What makes an application vulnerable sensitive data exposure?

• Transmission of data in clear text via protocols such as HTTP, SMTP and FTP.
• Sensitive data being stored, transmitted, or used unnecessarily in clear text.
• Use of old, weak, or non-standards-based cryptographic algorithms.

What’s the impact of sensitive data exposure?

• Compromise of regulated data (e.g. HIPAA or GDPR) resulting in fines.
• Identity hijacking resulting in costs to scrub or monitor data.
• Non-compliant status for privacy laws and regulations.

How can Fortify help with sensitive data exposure?

• If you are a developer: Fortify identifies sensitive data exposure and automates issue auditing.
• If you are in QA or Operations: Fortify removes findings mitigated outside the application context with templating.
• If you are in Operations: Fortify instruments logging and protection for applications in Java and .NET.

A4: XML external entities

XML External Entity issues can be introduced when an XML input containing a reference to an external entity is processed by a weakly configured parser. Examples are often found in applications that parse XML input from untrusted sources, when Document Type Definitions (DTDs) are enabled, or that use unpatched frameworks like SOAP 1.0. XML is everywhere—from SVG and image files to networking protocols and document formats such as PDF and RSS. Attackers reference external entities in XML input that results in processors exploited to extract data, execute code remotely, or impact network services.

What makes an application vulnerable to XML external entities?

• The application parses XML documents and processors have DTDs enabled.
• Using SAML for SSO, SOAP prior to v1.2, or .NET Framework prior to v2.0.
• The parser accepts untrusted sources or inserts untrusted XML data.

What’s the impact of XML external entities?

• Theft of sensitive data.
• Loading of attacker-controlled URL.
• Denial of Service Attacks (DoS).

How can Fortify help with XML external entities?

• If you are a developer: Fortify detects vulnerable XML parsers and recommends mitigating factors.
• If you are in QA or Operations: Fortify automatically scans for vulnerable XML parsers and validates exploit payloads.
• If you are in Operations: Fortify provides runtime logging and protection for issues in Java and .NET applications.

A5: Broken access control

Access control issues can be introduced when code and environmental restrictions overlap incompletely or are defined in multiple places for similar functionality. Examples are often found when security-by-obscurity is broken through forceful browsing to restricted pages, or when the application defines complex methods for access control in multiple ways and locations. Attackers can compromise access boundaries to steal sensitive data or disrupt operations.

What makes an application vulnerable to broken access control?

• Ability to act as a user without login, or an admin when logged in as a user.
• Manipulation of metadata or tokens for unauthorized or elevated privileges.
• Byzantine, unenforced, or scattered access control logic.

What’s the impact from broken access control?

• Unauthorized information disclosure or compromise of sensitive data.
• Modification or destruction of data.
• Takeover of site administration or users.

How can Fortify help with broken access control?

• If you are a developer: Fortify automates auditing and allows templating to remove issues mitigated elsewhere.
• If you are in QA and Operations: Fortify agents detect hidden attack surface and broken access control systems.
• If you are in Operations: Fortify instruments runtime access control logging for Java and .NET applications.

A6: Security misconfiguration

Security misconfiguration flaws can be introduced during the configuration of the application or its underlying environment. Misconfiguration can happen at any level of an application stack—from network services and application servers to containers and storage. Examples are often found in default accounts and configurations, "leaky" error messaging, or unpatched frameworks and services. Attackers can gain deployment information and access to privileged data to disrupt operations.

What makes an application vulnerable to security misconfiguration?

• Unnecessarily enabled default ports and accounts or unchanged passwords.
• Revealing stack trace or other messages in case of errors and exceptions.
• Not appropriately hardening security for the risk posed by any part of the stack.

What’s the impact of security misconfiguration?

Impact can vary from information disclosure to complete system compromise.

How can Fortify help with security misconfiguration?

• If you are a developer: Fortify identifies application dependencies and configuration files during scans.
• If you are in QA and Operations: Fortify dynamically evaluates application and server configurations for issues.
• If you are in Operations: Fortify provides open source analysis for reporting on environmental risks.

A7: Cross-Site scripting

Cross-Site Scripting (XSS) flaws can be introduced when untrusted, un-sanitized user input is executed as part of the HTML, or when users can be influenced to interact with malicious links. Examples are often found when familiar code constructs from languages such as JavaScript or Flash are accepted from untrusted sources or stored for later display by another user agent. Attackers can perform remote code execution on the user's machine, steal credentials, or deliver malware from redirect sites.

What makes an application vulnerable to cross-site scripting (XSS)?

There are three forms of XSS, usually targeting user agents such as browsers:

• Reflected XSS: The application or API includes untrusted input in HTML output.
• Stored XSS: Non-sanitized code saved to disk is triggered later by user action.
• DOM XSS: Applications, frameworks, and APIs that consume untrusted input.

What’s the impact of cross-site scripting (XSS)?

• Takeover of the victim’s account in the application.
• Retrieval of data from the target web application.
• Modification of content on the page.

How can Fortify help with cross-site scripting (XSS)?

• If you are a developer: Fortify detects XSS vulnerabilities in code and predicts the likelihood of exploit.
• If you are in QA and Operations: Fortify validates code dynamically for unsanitized inputs vulnerable to XSS.
• If you are in Operations: Fortify provides logging for Java and .NET events including unauthorized redirect.

A8: Insecure deserialization

Unsafe deserialization flaws can be introduced when languages and frameworks allow untrusted serialized data to be expanded into an object, often when web applications are communicating user or saving application state. Examples are often found when developers place no restrictions on methods that can self-execute during the deserialization process. Attackers leverage these "gadget chains" called outside of the application logic leverage to remotely execute code, deny service, or gain unauthorized access.

What makes an application vulnerable to insecure deserialization?

• The application deserializes data from untrusted sources.
• The application does not verify the source or contents before deserialization.
• Acceptable classes are not whitelisted to avoid unnecessary gadget exposure.

What’s the impact of insecure deserialization?

• These flaws can lead to remote code execution attacks, one of the most serious attacks possible.

How can Fortify help with insecure deserialization?

• If you are a developer: Fortify detects vulnerabilities in source code and provides component analysis.
• If you are in QA and Operations: Fortify instruments dynamically running applications to validate attack vectors.
• If you are in Operations: Fortify instruments logging for Java and .NET events including deserialization.

A9: Using components with known vulnerabilities

These flaws can be introduced when open source or third-party frameworks and libraries are introduced into an application and run with the same privileges. Examples are often found where component-based development results in a lack of understanding of the risks associated with dependencies and components or systems are difficult or impossible to patch. Attackers have leveraged vulnerable components for some of the largest breaches in history, though vulnerabilities can range from application compromise to remote code execution.

What makes an application vulnerable to open source or third-party frameworks and libraries?

• These can be accidental (e.g. coding error) or intentional (e.g. backdoored component).
• The application or environment uses unpatched or outdated components (one of the reasons application modernization is essential).
• Lack of scanning for vulnerabilities in third-party code or nested dependencies.
• Unavailable component inventories or ignored security bulletins.

What’s the impact of using components with known vulnerabilities?

While some known vulnerabilities lead to only minor impacts, some of the largest known breaches, such as Heartbleed and Shellshock, have relied on exploiting known vulnerabilities in shared components. Using components with known code vulnerabilities can result in remote code execution on the affected server, giving the attacker total control of the machine.

How can Fortify help with open source security?

• If you are developer: Fortify provides software component analysis via Sonatype integrations.
• If you are in QA and Operations: Fortify automates dynamic validation of known vulnerabilities at runtime.
• If you are in Operations: Fortify instruments logging and protection for Java and .NET application components.

A10: Insufficient logging and monitoring

Insufficient logging and monitoring flaws can be introduced when attack vectors or application misbehavior is not well understood or best practices of monitoring for indicators of compromise are not followed. Examples are often found in legacy systems without logging capabilities, when logs of application penetration testing go unexamined, or when logs do not provide sufficient detail for understanding what attackers did. Attackers rely on an average of around 200 days for detection that is typically discovered externally to establish persistence and pivot to additional vulnerable systems.

What makes an application vulnerable to insufficient logging and monitoring?

• Warnings and errors generate no, inadequate, or unclear log messages.
• Logs are stored locally without tamper controls and/or are unmonitored.
• Alert thresholds and response processes are insufficient or result in no action.

What’s the impact of insufficient logging and monitoring?

Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploits. Attackers may establish persistence, backdooring applications and operating systems, stealing data, or otherwise gaining unnoticed, unauthorized control of systems. If security critical information is not recorded or stored appropriately, there will be no trail for forensic analysis to discover the source of attack. Understanding that there is a problem at all may become more difficult, or impossible, if the attacker maintains control of logging capabilities.

How can Fortify help with insufficient logging and monitoring?

• If you are developer: Fortify scans logging capabilities in applications and APIs for vulnerabilities.
• If you are in QA and Operations: Fortify dynamic scans produce application logs for sufficiency review, like pen testing.
• If you are in Operations: Fortify instruments logging and protection for Java and .NET applications.

What's new for OWASP (2021)?

While it has only been four years since the last top 10 was released in 2017, there have been many changes in the cyber security industry which has made us think twice about top priority concerns or which new ones to add.

Three new categories were introduced:

A04:2021

Insecure Design: This category focuses on design flaws. This is needed because the movement for shifting left in development requires a shift left for threat modeling as well.

A08:2021

Software and Data Integrity Failures: Focuses on assumptions around software updates, critical data, and the CI/CD pipeline without verifying the integrity they can impact. This also incorporates the A08:2017 – Insecure Deserialization.

A10:2021

Server-Side Request Forgery (SSRF): This category is mostly in the top 10 from the community survey. They really stressed this vulnerability because of the above average exploitability and impact.

Other changes

The other categories either had name changes, moved ranks, or were consolidated into other categories:

• A01:2017 – Injection moved down to A:03.
• A02:2017 – Broken Authentication was renamed Identification and Authentication Failures and moved down to A07.
• A03:2017 – Sensitive Data Exposure was moved up to A02 renamed Cryptographic Failures to more fully address the root cause, not just the symptoms.
• A05:2017 – Broken Access Control moved to A01 because 94% of applications they tested showed exposure to some form of Broken Access Control.
• A06:2017 – Security Misconfiguration was moved up one spot to A05.
• A07:2017 – Cross-Site Scripting (XSS) was consolidated into A03 Injection.
• A09:2017 – Using Components with Known Vulnerabilities was moved up to A06 and renamed Vulnerable and Outdated Components. This change was greatly due to the community ranking it #2 on their list.
• A10:2017 – Insufficient Logging & Monitoring moved up to A09 and is now called Security Logging and Monitoring Failures.

Want to see how Fortify can help your organization? Start Your Free 15-Day Trial of Fortify on Demand by OpenText™ Now