Last updated

July 3, 2025

{x} minute read

What are the OWASP Top 10?

Get a demo

Free trial

Download the PDF guide

Free trial

Written by

Abi Tyas Tunggal

Writer and Senior Product Manager at UpGuard.

Abi's work has influenced leaders across cybersecurity, technology, and financial services.

Reviewed by

Kaushik Sen

Chief Marketing Officer

Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education.

Table of contents

The OWASP Top 10 is a regularly-updated report outlining the top 10 list of security concerns for web application security.

The report is put together by a team of security experts around the world. OWASP refers to the Top 10 as an 'awareness document' and they recommend all companies incorporate the report's findings into the cybersecurity processes.

What is OWASP?

The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to improving web application security.

OWASP produces freely-available articles, methodologies, documentation, tools, and technologies, making it possible for anyone to improve their web application security.

The OWASP Top 10 is one of their most well-known projects.

What are the Top 10 Web Application Security Risks?

1. Injection

Injection attacks happen when unvalidated or untrusted data is sent to a code interpreter through form input or another data submission field to a web application.

Successful injection attacks can result in data leaks, data corruption, data breaches, loss of accountability, and denial of access.

Almost any source of data can be an injection vector including environment variables, parameters, external and internal web services, and all types of users.

For example, an attacker could inject SQL code into a form that expects a plain text username. If the web application developer has not properly sanitized the input, it could result in the SQL code being executed. This is known as an SQL injection attack.

SQL injection is not the only injection flaw. Common vulnerabilities include XPath, NoSQL, LDAP injections, as well as OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.

In general, an application is vulnerable if:

User input is not validated, filtered or sanitized
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 sensitive records
Hostile data is directly used or concatenated, such that the SQL or command contains the structure and hostile data in dynamic queries, commands or stored procedures

To prevent injection attacks, user input should be validated and/or sanitized, and where possible use an API that avoids the use of the interpreter entirely.

For server-side input, whitelist input validation, and use LIMIT and other SQL controls within queries to minimize the amount of sensitive data that can be exposed.

To learn more about preventing injection attacks, OWASP recommends:

OWASP Proactive Controls: Parameterize Queries
OWASP ASVS: V5 Input Validation and Encoding
OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection
OWASP Cheat Sheet: Injection Prevention
OWASP Cheat Sheet: SQL Injection Prevention
OWASP Cheat Sheet: Injection Prevention in Java
OWASP Cheat Sheet: Query Parameterization
OWASP Automated Threats to Web Applications – OAT-014
CWE-77: Command Injection
CWE-89: SQL Injection
CWE-564: Hibernate Injection
CWE-917: Expression Language Injection
PortSwigger: Server-side template injection

2. Broken Authentication

Authentication systems are some of the most poorly designed and/or implemented systems on many web applications. Additionally, session management is the foundation of any authentication and access control system and is present in all stateful applications.

These vulnerabilities can be detected by an attacker using manual means and exploited using automated tools, brute force attacks, and dictionary attack tools. Read our full post on brute force attacks here.

The success rate of these attacks can be high. Hundreds of millions of username and password combinations have been exposed in large data breaches. And many people reuse passwords across services or don't bother to change the default administrative login credentials.

Additionally, session management attacks, like cookie hijacking, are well understood and easily exploitable.

OWASP states that a web application has poor authentication if it:

Permits automated attacks, e.g. credential stuffing
Permits brute force or other automated attacks
Permits default, weak or well-known passwords (read our password security checklist)
Uses weak or ineffective credential recovery or forgot password flows, that rely on knowledge-based answers that can be exposed on social media
Uses plain text, unencrypted or weakly hashed passwords
Has missing or ineffective multi-factor authentication (e.g. no 2FA and biometrics)
Exposes Session IDs in the URL
Does not rotate Session IDs after login
Does not properly invalidate session tokens

There are a number of ways to prevent cyber attacks that exploit poor or broken authentication, including:

Multi-factor authentication that prevents automated credential stuffing, brute force, and stolen credential re-use attacks
Never using default credentials
Weak password checks that disallow the top 10,000 worst passwords and ones exposed in known data breaches
Aligning password length, complexity, and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets
Ensuring registration, credential recovery, and API pathways are hardened against enumeration attacks by returning the same message for all outcomes
Limiting and/or increasing the delay for failed login attempts
Logging all login failures and alerting your security team when credential stuffing, brute force or other attacks are detected
Using server-side, secure, built-in session management that generates a new, random Session ID with high entropy after login
Not exposing Session IDs in the URL
Invalidating user sessions on logout, idle, and absolute timeouts

To learn more about preventing broken authentication attacks, OWASP recommends:

OWASP Proactive Controls: Implement Identity and Authentication Controls
OWASP Application Security Verification Standard: V2 Authentication
OWASP Application Security Verification Standard: V3 Session Management
OWASP Testing Guide: Identity, Authentication
OWASP Cheat Sheet: Authentication
OWASP Cheat Sheet: Credential Stuffing
OWASP Cheat Sheet: Forgot Password
OWASP Cheat Sheet: Session Management
OWASP Automated Threats Handbook
NIST 800-63b: 5.1.1 Memorized Secrets
CWE-287: Improper Authentication
CWE-384: Session Fixation

3. Sensitive Data Exposure

Many web applications and their APIs don't sufficiently protect sensitive data, such as financials, PHI, and PII.

This means rather than attacking the cipher directly, attackers may steal keys, execute man-in-the-middle attacks or steal clear text data from the server, while in transit, from the victim's browser, and increasingly, from a third-party vendor who has poor information security.

As organizations store and process more sensitive data and worldwide data protection laws are introduced, this becomes a larger cybersecurity risk for any web application. With the most common mistake simply not encrypting data at all.

When encryption is employed, weak key generation and management, weak algorithm, protocol, and cipher usage are common, particularly weak password hashing storage techniques.

Failure to protect sensitive data can result in industrial espionage, reputational damage, financial cost, and increasingly, regulatory action. Driven by new laws and regulations, such as GDPR, LGPD, CCPA, PIPEDA, HIPAA, and CPS 234 that require the protection of PII, PHI and other sensitive information.

Once exposed, credit card numbers, health records, personal information, and trade secrets and result in fraud, identity theft, loss of market position, and cybercrime.

To prevent sensitive data exposure, OWASP recommends:

Classifying data processed, stored or transmitted into sensitivity buckets based on laws, regulations, and business needs
Applying controls adequate for the data classification
Not storing sensitive data unless necessary
Encrypting sensitive data at rest
Ensuring encryption algorithms are up-to-date and strong
Using proper key management
Encrypting data in transit with secure protocols (e.g. TLS)
Enforcing encryption through HTTP Strict Transport Security (HSTS)
Not caching sensitive data
Storing passwords using strong, adaptive, and salted hashing functions e.g. Argon2, scrypt, bcrypt or PBKDF2.
Verifying the effectiveness of configuration and settings

UpGuard Breach Risk can help you detect leaked credentials and exposed data before it falls into the wrong hands. We were able to detect data exposed in a GitHub repository by an AWS engineer in 30 minutes. We were able to do this because we actively discover exposed datasets on the open and deep web, scouring S3 buckets, public GitHub repos, and unsecured RSync and FTP servers.

To learn more about preventing sensitive data exposures, OWASP recommends:

4. XML External Entities (XXE)

Attackers can exploit vulnerable Extensible Markup Language (XML) processors that upload XML or include hostile content in an XML document.

This is because many old XML processors allow the specification of an external entity, e.g. a hard drive.

This means that, like injection attacks, XML parsers can be coerced into sending data to an unauthorized external entity, which then passes the sensitive data directly to an attacker.

These flaws can also be used to execute remote requests from the server, scan internal systems, and perform denial-of-service attacks.

To prevent XXE attacks:

Use simple data formats (like JSON) and avoid serialization of sensitive data
Patch or upgrade all XML processors and libraries in use
Disable XML external entity and DTD processing in XML parsers
Whitelist server-side input
Validate, filter or sanitize input to prevent hostile data within XML documents, headers, and nodes
Verify that XML and XSL upload functionality validates incoming XML using XSD validation or something similar
Manually review code and use SAST tools to help detect XXEs in source code.

To learn more about preventing XXE attacks, OWASP recommends:

5. Broken Access Control

Access control refers to the systems that control access to information or functionality.

Poor access control implementation allows attackers to bypass authorization or perform tasks as though they are privileged users.

For example, a web application may allow a user to change which account they are logged into by changing part of the URL, without any additional verification.

Common access control security vulnerabilities include:

Bypassing access control checks by modifying the URL, internal application state, HTML of the web page, or by using a custom API attack tool
Allowing the primary key to be changed to another user record, permitting viewing or editing of another user's account
Privilege escalation attacks that impersonate a user or allow a user to impersonate an admin
Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT), access control token, cookie, or hidden field
CORS misconfiguration that allows unauthorized API access
Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user

To prevent access control access, ensure that access control checks and metadata cannot be modified by:

Denying access by default (the principle of least privilege)
Implementing access control mechanisms once and reusing them across the application
Enforcing record ownership rather than accepting users can create, read, update or delete any record
Disabling web server directory listing
Ensuring metadata and backup files are not present within web roots
Logging access control failures and alerting the security team where necessary
Rate limiting APIs and controller access to minimize the impact of automated attacks
Invalidating JWT tokens on logout

To learn more about preventing access control exploits, OWASP recommends:

6. Security Misconfiguration

Attackers can exploit unpatched application vulnerabilities or access default accounts, unused pages, unprotected and directories to gain unauthorized access to or gather information on a system.

Misconfiguration can happen at any level of an application stack including network services, platform, web server, application server, database, frameworks, custom code, pre-installed virtual machines, containers, and storage.

To prevent misconfiguration:

Implement an automated configuration management policy
Run a repeatable hardening process that makes it easy to deploy another secure environment. See our Windows Server Hardening Checklist
Use a minimal platform without unnecessary features, components, documentation, and samples
Implement vulnerability management processes
Segment application architecture to separate components or tenants with segmentation, containerization or cloud security groups

Misconfiguration doesn't end with your organization. Use UpGuard Vendor Risk to send security questionnaires to third-parties and your security ratings to automatically detect first, third and fourth-party configuration issues and vulnerabilities.

To learn more about preventing misconfiguration, OWASP recommends:

7. Cross-Site Scripting (XSS)

Cross-site scripting (XSS) occurs when web applications allow users to add custom code to a URL path or a website that will be seen by other users.

These vulnerabilities can be exploited to run malicious JavaScript on the victim's browser.

For example, an attacker could send a phishing email to a victim that appears to be from their bank, with a link to the bank's legitimate website.

If the bank doesn't prevent cross-site scripting, the attacker could add malicious JavaScript to the end of the URL, and run it when the link is clicked.

Attackers can also use XSS to stop any automated Cross-Site Request Forgery (CSRF) defenses.

To prevent cross-site scripting:

Use modern frameworks that escape XSS by design, such as Ruby on Rails or React
Learn the limitations of a framework's XSS protection and appropriately handle the exceptions
Escape untrusted HTTP requests
Validate, filter or sanitize user-generated content
Use a Content Security Policy (CSP) as a defense-in-depth control

To learn more about preventing XSS, OWASP recommends:

8. Insecure Deserialization

This web security risk targets web applications that frequently serialize and deserialize data.

Serialization is the process of translating data structures or object states into a format that can be stored or transmitted, then reconstructed later.

Deserialization is the opposite, converting serialized data into objects the application can use.

When data from an untrusted source is deserialized it can result in DDoS attacks and remote code execution.

To prevent insecure deserialization:

Implement integrity checks, such as digital signatures, on any serialized objects to prevent object creation and data tampering
Enforce strict type constraints during deserialization and before object creation
Isolate and run deserialization code in low privilege environments
Log exceptions and failures, such as when the incoming type is not the expected type or when an exception is thrown
Restrict and monitor incoming and outgoing network traffic from containers or servers that deserialize
Monitor deserialization and alert DevOps if a user deserializes constantly

To learn how to prevent insecure deserialization, OWASP recommends:

9. Using Components with Known Vulnerabilities

The use of libraries and frameworks is on the rise, which can introduce vulnerable components that attackers can exploit.

These components speed up software development, helping developers avoid redundant work and providing needed functionality.

Common examples include front-end frameworks like React, back-end frameworks like Ruby on Rails, shared icons or A/B testing solutions.

The most popular components are used by millions of websites, which means if attackers can find security issues in one can leave millions of web applications exposed.

Component developers issue software security patches and updates to fix or mitigate known vulnerabilities (like those listed on CVE), but developers don't always install patches or use the most recent version of components.

To minimize this risk, developers should remove unused components and ensure they are receiving components from a trusted source as malicious sites may post as open source projects to spread malware.

To prevent known vulnerabilities, OWASP recommends:

10. Insufficient Logging & Monitoring

Many web applications do not take the necessary steps to detect data breaches. In fact, the average discovery time for breach discovery was 206 days in 2019.

This can give attackers a long time to cause damage before incident response plans can kick in.

OWASP recommends that applications:

Ensure all login, access control failures, and server-side input validation failures are logged with sufficient context to identify suspicious or malicious accounts and held for sufficient time to allow for delayed forensic analysis
Have logs generated in a format that can be easily consumed by a centralized log management solution
Have an audit trail for high-value transactions with integrity controls to prevent tampering or deletion, such as append-only database tables
Have effective monitoring and alerting so suspicious activity can be detected and responded to in a timely manner
Establish an incident response plan and disaster recovery plan as outlined in NIST 700-61 rev 2

For further reading, OWASP recommends:

How UpGuard Can Reduce Web Risks

UpGuard Vendor Risk can minimize the amount of time your organization spends assessing related and third-party information security controls by automating vendor questionnaires and providing vendor questionnaire templates.

We can help you continuously monitor your vendors' external security controls and provide an unbiased security rating based on the analysis of 70+ attack vectors including: