Open Worldwide Application Security Project

OWASP Vulnerability
What is the OWASP Top 10?
A list of the top ten web application vulnerabilities

● Determined by OWASP and the security community at large

● Released every few years
● Most recently released in 2021
● First release in 2003
OWASP Top 10 Vulnerability 2021
A01:2021 – Broken Access Control - Overview
● 94% of applications were tested for some form of broken access control with
the average incidence rate of 3.81%, and has the most occurrences in the
contributed dataset with over 318k.
● Access control enforces policy such that users cannot act outside of their
intended permissions.
● Failures typically lead to unauthorized information disclosure, modification, or
destruction of all data or performing a business function outside the user's
limits.
Broken Access Control - Description

● Violation of the principle of least privilege or deny by default, where access

should only be granted for particular capabilities, roles, or users, but is
available to anyone.
● Bypassing access control checks by modifying the URL (parameter tampering
or force browsing), internal application state, or the HTML page, or by using
an attack tool modifying API requests.
● Permitting viewing or editing someone else's account, by providing its unique
identifier.
● Metadata manipulation, such as replaying or tampering with a JSON Web
Token (JWT) access control token, or a cookie or hidden field manipulated to
elevate privileges or abusing JWT invalidation.
Broken Access Control - How to Prevent?

● Except for public resources, deny by default.

● Implement access control mechanisms once and re-use them throughout the application,
including minimizing Cross-Origin Resource Sharing (CORS) usage.
● Model access controls should enforce record ownership rather than accepting that the
user can create, read, update, or delete any record.
● Disable web server directory listing and ensure file metadata and backup files are not
present within web roots.
● Log access control failures, alert admins when appropriate
● Stateful session identifiers should be invalidated on the server after logout. Stateless
JWT tokens should rather be short-lived so that the window of opportunity for an attacker
is minimized.
Broken Access Control - Example Attack Scenario
● Scenario #1: The application uses unverified data in a SQL call that is accessing account
information:
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the browser's 'acct' parameter to send whatever account number
they want. If not correctly verified, the attacker can access any user's account.
● Scenario #2: An attacker simply forces browses to target URLs. Admin rights are required for
access to the admin page.
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the
admin page, this is a flaw.
A02:2021 – Cryptographic Failures - overview
● Previously known as Sensitive Data Exposure, which is more of a broad symptom
rather than a root cause, the focus is on failures related to cryptography.
● This often lead to exposure of sensitive data.
● Notable Common Weakness Enumerations (CWEs) included are CWE-259: Use of
Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm, and CWE-331
Insufficient Entropy.
● The protection needs of data in transit and at rest. For example, passwords, credit
card numbers, health records, personal information, and business secrets require
extra protection, mainly if that data falls under privacy laws.
A02:2021 – Cryptographic Failures - Description

● Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, FTP
also using TLS upgrades like STARTTLS. External internet traffic is hazardous. Verify all
internal traffic, e.g., between load balancers, web servers, or back-end systems
● Are any old or weak cryptographic algorithms or protocols used either by default or in older
code?
● Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key
management or rotation missing? Are crypto keys checked into source code repositories?
● Is the received server certificate and the trust chain properly validated?
● Are initialization vectors ignored, reused, or not generated sufficiently secure for the
cryptographic mode of operation?
A02:2021 – Cryptographic Failures - How to Prevent?

● Classify data processed, stored, or transmitted by an application. Identify which data is

sensitive according to privacy laws, regulatory requirements, or business needs.
● Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS
compliant tokenization or even truncation. Data that is not retained cannot be stolen.
● Make sure to encrypt all sensitive data at rest.
● Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use
proper key management.
A02:2021 – Cryptographic Failures - How to Prevent?

● Encrypt all data in transit with secure protocols such as TLS with forward secrecy (FS)
ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using
directives like HTTP Strict Transport Security (HSTS).
● Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.
● Keys should be generated cryptographically randomly and stored in memory as byte arrays.
If a password is used, then it must be converted to a key via an appropriate password base
key derivation function.
Cryptographic Failures - Example Attack Scenarios

● Scenario #1: An application encrypts credit card numbers in a database using automatic
database encryption. However, this data is automatically decrypted when retrieved, allowing
a SQL injection flaw to retrieve credit card numbers in clear text.
● Scenario #2: A site doesn't use or enforce TLS for all pages or supports weak encryption. An
attacker monitors network traffic (e.g., at an insecure wireless network), downgrades
connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie.
The attacker then replays this cookie and hijacks the user's (authenticated) session,
accessing or modifying the user's private data. Instead of the above they could alter all
transported data, e.g., the recipient of a money transfer.
A03:2021 – Injection - Overview
● 94% of the applications were tested for some form of injection with a max incidence
rate of 19%, an average incidence rate of 3%, and 274k occurrences. Notable Common
Weakness Enumerations (CWEs) included are CWE-79: Cross-site Scripting, CWE-89:
SQL Injection, and CWE-73: External Control of File Name or Path.
A03:2021 – Injection - Description

An application is vulnerable to attack when:

● User-supplied data is not validated, filtered, or sanitized by the application.

● Dynamic queries or non-parameterized calls without context-aware escaping are used
directly in the interpreter.
● Hostile data is used within object-relational mapping (ORM) search parameters to extract
additional, sensitive records.
● Hostile data is directly used or concatenated. The SQL or command contains the structure
and malicious data in dynamic queries, commands, or stored procedures.

Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping
(ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL)
injection.Source code review is the best method of detecting if applications are vulnerable to
injections.
A03:2021 – Injection - How to Prevent?

Preventing injection requires keeping data separate from commands and queries:

● The preferred option is to use a safe API, which avoids using the interpreter entirely,
provides a parameterized interface, or migrates to Object Relational Mapping Tools
(ORMs).
● Use positive server-side input validation. This is not a complete defense as many
applications require special characters, such as text areas or APIs for mobile
applications.
● For any residual dynamic queries, escape special characters using the specific escape
syntax for that interpreter.
● Use LIMIT and other SQL controls within queries to prevent mass disclosure of records
in case of SQL injection.
A03:2021 – Injection - Example Attack Scenarios

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g.,
Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") +

"'");

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ' UNION SLEEP(10);--. For example:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

A04:2021 – Insecure Design - Overview
● Focuses on risks related to design and architectural flaws, with a call for more use of
threat modeling, secure design patterns, and reference architectures.

● As a community we need to move beyond "shift-left" in the coding space to pre-code

activities that are critical for the principles of Secure by Design.

● Notable Common Weakness Enumerations (CWEs) include

○ CWE-209: Generation of Error Message Containing Sensitive Information,

○ CWE-256: Unprotected Storage of Credentials,

○ CWE-501: Trust Boundary Violation, and

○ CWE-522: Insufficiently Protected Credentials.

A04:2021 – Insecure Design - Description
● Insecure design is a broad category representing different weaknesses, expressed as
“missing or ineffective control design.”

● A secure design can still have implementation defects leading to vulnerabilities that
may be exploited. An insecure design cannot be fixed by a perfect implementation as
by definition, needed security controls were never created to defend against specific
attacks.

● One of the factors that contribute to insecure design is the lack of business risk
profiling inherent in the software or system being developed, and thus the failure to
determine what level of security design is required.
A04:2021 – Insecure Design - How to Prevent?

● Establish and use a secure development lifecycle with AppSec professionals to help
evaluate and design security and privacy-related controls
● Establish and use a library of secure design patterns or paved road ready to use
components
● Use threat modeling for critical authentication, access control, business logic, and key
flows
● Integrate security language and controls into user stories
● Integrate plausibility checks at each tier of your application (from frontend to backend)
● Segregate tier layers on the system and network layers depending on the exposure and
protection needs
● Segregate tenants robustly by design throughout all tiers
● Limit resource consumption by user or service
A04:2021 – Insecure Design - Example Attack Scenarios

● Scenario:

● A credential recovery workflow might include “questions and answers,” which is

prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and
answers cannot be trusted as evidence of identity as more than one person can know
the answers, which is why they are prohibited. Such code should be removed and
replaced with a more secure design.
A05:2021 – Security Misconfiguration - Overview

● 90% of applications were tested for some form of misconfiguration, with an

average incidence rate of 4.0%, and over 208k occurrences of a Common
Weakness Enumeration (CWE) in this risk category.
A05:2021 – Security Misconfiguration - Description

The application might be vulnerable if the application is:

● Missing appropriate security hardening across any part of the application stack or
improperly configured permissions on cloud services.
● Unnecessary features are enabled or installed (e.g., unnecessary ports, services,
pages, accounts, or privileges).
● Default accounts and their passwords are still enabled and unchanged.
● Error handling reveals stack traces or other overly informative error messages to
users.
● For upgraded systems, the latest security features are disabled or not configured
securely.
● The security settings in the application servers, application frameworks , libraries,
databases, etc., are not set to secure values.
A05:2021 – Security Misconfiguration - How to prevent?

● A repeatable hardening process makes it fast and easy to deploy another

environment that is appropriately locked down. Development, QA, and
production environments should all be configured identically, with different
credentials used in each environment. This process should be automated to
minimize the effort required to set up a new secure environment.

● A minimal platform without any unnecessary features, components,

documentation, and samples. Remove or do not install unused features and
frameworks.
A05:2021 – Security Misconfiguration - How to prevent?

● A task to review and update the configurations appropriate to all security

notes, updates, and patches as part of the patch management process.
Review cloud storage permissions.

● A segmented application architecture provides effective and secure

separation between components or tenants, with segmentation,
containerization, or cloud security groups (ACLs).

● An automated process to verify the effectiveness of the configurations and

settings in all environments.
Security Misconfiguration - Example Attack Scenarios
● Scenario #1: The application server comes with sample applications not removed from
the production server. These sample applications have known security flaws attackers
use to compromise the server. Suppose one of these applications is the admin
console, and default accounts weren't changed. In that case, the attacker logs in with
default passwords and takes over.
● Scenario #2: Directory listing is not disabled on the server. An attacker discovers they
can simply list directories. The attacker finds and downloads the compiled Java
classes, which they decompile and reverse engineer to view the code. The attacker
then finds a severe access control flaw in the application.
● Scenario #3: The application server's configuration allows detailed error messages,
e.g., stack traces, to be returned to users. This potentially exposes sensitive
information or underlying flaws such as component versions that are known to be
vulnerable.
A06:Vulnerable and Outdated Components - Overview

Vulnerable Components are a known issue that we struggle to test and assess risk
and is the only category to not have any Common Vulnerability and Exposures
(CVEs) mapped to the included CWEs, so a default exploits/impact weight of 5.0 is
used.
A06:Vulnerable and Outdated Components - Description

You are likely vulnerable:

● If you do not know the versions of all components you use (both client-side
and server-side). This includes components you directly use as well as
nested dependencies.
● If the software is vulnerable, unsupported, or out of date. This includes the
OS, web/application server, database management system (DBMS),
applications, APIs and all components, runtime environments, and libraries.
● If you do not scan for vulnerabilities regularly and subscribe to security
bulletins related to the components you use.
A06: Vulnerable and Outdated Components - Description

You are likely vulnerable:

● If you do not fix or upgrade the underlying platform, frameworks, and

dependencies in a risk-based, timely fashion. This commonly happens in
environments when patching is a monthly or quarterly task under change
control, leaving organizations open to days or months of unnecessary
exposure to fixed vulnerabilities.
● If software developers do not test the compatibility of updated, upgraded, or
patched libraries.
A06:Vulnerable and Outdated Components - How to Prevent?

There should be a patch management process in place to:

● Remove unused dependencies, unnecessary features, components, files, and

documentation.

● Only obtain components from official sources over secure links. Prefer signed
packages to reduce the chance of including a modified, malicious component

● Monitor for libraries and components that are unmaintained or do not create
security patches for older versions. If patching is not possible, consider deploying
a virtual patch to monitor, detect, or protect against the discovered issue.
Example Attack Scenarios

● Scenario #1: Components typically run with the same privileges as the
application itself, so flaws in any component can result in serious impact.
Such flaws can be accidental (e.g., coding error) or intentional (e.g., a
backdoor in a component).
 A07:2021 – Identification and Authentication Failures -
Overview

● Previously known as Broken Authentication, this category slid down

from the second position and now includes Common Weakness
Enumerations (CWEs) related to identification failures.
A07:2021 Identification and Authentication Failures - Description

Confirmation of the user's identity, authentication, and session management is critical to protect against
authentication-related attacks.

There may be authentication weaknesses if the application:

● Permits automated attacks such as credential stuffing, where the attacker has a list of valid
usernames and passwords.
● Permits brute force or other automated attacks.
● Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin".
● Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-
based answers," which cannot be made safe.
● Uses plain text, encrypted, or weakly hashed passwords data stores
● Has missing or ineffective multi-factor authentication.
● Exposes session identifier in the URL.
● Reuse session identifier after successful login.
Identification and Authentication Failures - How to Prevent?

● Where possible, implement multi-factor authentication to prevent automated

credential stuffing, brute force, and stolen credential reuse attacks.
● Do not ship or deploy with any default credentials, particularly for admin
users.
● Implement weak password checks, such as testing new or changed
passwords against the top 10,000 worst passwords list.
● Align password length, complexity, and rotation policies with National
Institute of Standards and Technology (NIST) 800-63b's guidelines in section
5.1.1 for Memorized Secrets or other modern, evidence-based password
policies.
Identification and Authentication Failures - How to Prevent?

● Ensure registration, credential recovery, and API pathways are hardened

against account enumeration attacks by using the same messages for all
outcomes.
● Limit or increasingly delay failed login attempts, but be careful not to create a
denial of service scenario. Log all failures and alert administrators when
credential stuffing, brute force, or other attacks are detected.
● Use a server-side, secure, built-in session manager that generates a new
random session ID with high entropy after login. Session identifier should not
be in the URL, be securely stored, and invalidated after logout, idle, and
absolute timeouts.
Example Attack Scenarios

● Scenario #1: Credential stuffing, the use of lists of known passwords, is a common
attack. Suppose an application does not implement automated threat or credential
stuffing protection. In that case, the application can be used as a password oracle to
determine if the credentials are valid.
● Scenario #2: Most authentication attacks occur due to the continued use of passwords
as a sole factor. Once considered best practices, password rotation and complexity
requirements encourage users to use and reuse weak passwords. Organizations are
recommended to stop these practices per NIST 800-63 and use multi-factor
authentication.
● Scenario #3: Application session timeouts aren't set correctly. A user uses a public
computer to access an application. Instead of selecting "logout," the user simply closes
the browser tab and walks away. An attacker uses the same browser an hour later, and
the user is still authenticated.
A08:2021 – Software and Data Integrity Failures - Overview
● A new category for 2021 focuses on making assumptions related to software updates,
critical data, and CI/CD pipelines without verifying integrity. One of the highest
weighted impacts from Common Vulnerability and Exposures/Common Vulnerability
Scoring System (CVE/CVSS) data.
A08:2021 – Software and Data Integrity Failures - Description
● Software and data integrity failures relate to code and infrastructure that does not
protect against integrity violations. An example of this is where an application relies
upon plugins, libraries, or modules from untrusted sources, repositories, and content
delivery networks (CDNs).
● An insecure CI/CD pipeline can introduce the potential for unauthorized access,
malicious code, or system compromise. Lastly, many applications now include auto-
update functionality, where updates are downloaded without sufficient integrity
verification and applied to the previously trusted application.
● Attackers could potentially upload their own updates to be distributed and run on all
installations. Another example is where objects or data are encoded or serialized into a
structure that an attacker can see and modify is vulnerable to insecure deserialization.
Software and Data Integrity Failures - How to prevent?

● Use digital signatures or similar mechanisms to verify the software or data is from the
expected source and has not been altered.
● Ensure libraries and dependencies, such as npm or Maven, are consuming trusted
repositories. If you have a higher risk profile, consider hosting an internal known-good
repository that's vetted.
● Ensure that a software supply chain security tool, such as OWASP Dependency Check or
OWASP CycloneDX, is used to verify that components do not contain known vulnerabilities
● Ensure that there is a review process for code and configuration changes to minimize the
chance that malicious code or configuration could be introduced into your software
pipeline.
● Ensure that your CI/CD pipeline has proper segregation, configuration, and access control
to ensure the integrity of the code flowing through the build and deploy processes.
● Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients
without some form of integrity check or digital signature to detect tampering or replay of
Software and Data Integrity Failures - Example Attack
Scenarios
● Scenario #1 Update without signing: Many home routers, set-top boxes, device
firmware, and others do not verify updates via signed firmware. Unsigned firmware is a
growing target for attackers and is expected to only get worse. This is a major concern
as many times there is no mechanism to remediate other than to fix in a future version
and wait for previous versions to age out.
● Scenario #2 SolarWinds malicious update: Nation-states have been known to attack
update mechanisms, with a recent notable attack being the SolarWinds Orion attack.
The company that develops the software had secure build and update integrity
processes. Still, these were able to be subverted, and for several months, the firm
distributed a highly targeted malicious update to more than 18,000 organizations, of
which around 100 or so were affected. This is one of the most far-reaching and most
significant breaches of this nature in history.
A09:2021 – Security Logging and Monitoring Failures - Overview

● Logging and monitoring can be challenging to test, often involving interviews or asking
if attacks were detected during a penetration test.There isn't much CVE/CVSS data for
this category, but detecting and responding to breaches is critical. Still, it can be very
impactful for accountability, visibility, incident alerting, and forensics.
A09:2021– Security Logging and Monitoring Failures -
Description
This category is to help detect, escalate, and respond to active breaches. Without logging
and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring,
and active response occurs any time:

● Auditable events, such as logins, failed logins, and high-value transactions, are not
logged.
● Warnings and errors generate no, inadequate, or unclear log messages.
● Logs of applications and APIs are not monitored for suspicious activity.
● Logs are only stored locally.
● Appropriate alerting thresholds and response escalation processes are not in place
or effective.
● Penetration testing and scans by dynamic application security testing (DAST) tools
(such as OWASP ZAP) do not trigger alerts.
● The application cannot detect, escalate, or alert for active attacks in real-time or
Security Logging and Monitoring Failures - How to Prevent
Developers should implement some or all the following controls, depending on the risk of the
application:

● Ensure all login, access control, and server-side input validation failures can be logged
with sufficient user context to identify suspicious or malicious accounts and held for
enough time to allow delayed forensic analysis.
● Ensure that logs are generated in a format that log management solutions can easily
consume.
● Ensure log data is encoded correctly to prevent injections or attacks on the logging or
monitoring systems.
● Ensure high-value transactions have an audit trail with integrity controls to prevent
tampering or deletion, such as append-only database tables or similar.
● DevSecOps teams should establish effective monitoring and alerting such that suspicious
activities are detected and responded to quickly.
● Establish or adopt an incident response and recovery plan, such as National Institute of
Standards and Technology (NIST) 800-61r2 or later.
Security Logging and Monitoring Failures - Example Scenarios
Scenario #1: A children's health plan provider's website operator couldn't detect a breach due to a
lack of monitoring and logging. An external party informed the health plan provider that an attacker
had accessed and modified thousands of sensitive health records of more than 3.5 million
children. A post-incident review found that the website developers had not addressed significant
vulnerabilities. As there was no logging or monitoring of the system, the data breach could have
been in progress since 2013, a period of more than seven years.

Scenario #2: A major Indian airline had a data breach involving more than ten years' worth of
personal data of millions of passengers, including passport and credit card data. The data breach
occurred at a third-party cloud hosting provider, who notified the airline of the breach after some
time.

Scenario #3: A major European airline suffered a GDPR reportable breach. The breach was
reportedly caused by payment application security vulnerabilities exploited by attackers, who
harvested more than 400,000 customer payment records. The airline was fined 20 million pounds
as a result by the privacy regulator.
A10:2021 – Server-Side Request Forgery (SSRF) - Overview

● The data shows a relatively low incidence rate with above average testing coverage
and above-average Exploit and Impact potential ratings. As new entries are likely to be
a single or small cluster of Common Weakness Enumerations (CWEs) for attention and
awareness, the hope is that they are subject to focus and can be rolled into a larger
category in a future edition.
A10:2021 – Server-Side Request Forgery (SSRF) - Description

● SSRF flaws occur whenever a web application is fetching a remote resource without
validating the user-supplied URL. It allows an attacker to coerce the application to send
a crafted request to an unexpected destination, even when protected by a firewall, VPN,
or another type of network access control list (ACL).
● As modern web applications provide end-users with convenient features, fetching a
URL becomes a common scenario. As a result, the incidence of SSRF is increasing.
Also, the severity of SSRF is becoming higher due to cloud services and the complexity
of architectures.
 Server-Side Request Forgery (SSRF) - How to Prevent

From Network layer

● Segment remote resource access functionality in separate networks to reduce the impact of SSRF
● Enforce “deny by default” firewall policies or network access control rules to block all but essential
intranet traffic.

From Application layer:

● Sanitize and validate all client-supplied input data

● Enforce the URL schema, port, and destination with a positive allow list
● Do not send raw responses to clients
● Disable HTTP redirections
 Server-Side Request Forgery (SSRF) - How to Prevent

Additional Measures to consider:

● Don't deploy other security relevant services on front systems (e.g. OpenID). Control local
traffic on these systems (e.g. localhost)
● For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs)
on independent systems to consider very high protection needs
 Server-Side Request Forgery (SSRF) - Example Attack Scenarios

Scenario #1: Port scan internal servers – If the network architecture is unsegmented,
attackers can map out internal networks and determine if ports are open or closed on
internal servers from connection results or elapsed time to connect or reject SSRF payload
connections.

Scenario #2: Sensitive data exposure – Attackers can access local files or internal services
to gain sensitive information such as file:///etc/passwd and
http://localhost:28017/.

Scenario #3: Access metadata storage of cloud services – Most cloud providers have
metadata storage such as http://169.254.169.254/. An attacker can read the metadata
to gain sensitive information.

Scenario #4: Compromise internal services – The attacker can abuse internal services to
conduct further attacks such as Remote Code Execution (RCE) or Denial of Service (DoS).