OWASP Top 10 Explained: Every Vulnerability and How to Protect Your App

In November 2025, OWASP published the OWASP Top 10 2025, the first major revision of its application security risk ranking since 2021. If you build, secure, or audit web applications, this is the list that shapes how the industry talks about risk: the categories appear in security training, pentest reports, vendor datasheets, and a growing number of compliance frameworks. The 2025 edition keeps Broken Access Control at number one, promotes Security Misconfiguration to second place, and introduces two structural changes that matter for how you defend modern software.

This guide explains every category in the OWASP Top 10 2025, what actually changed since 2021 (including the version confusion that trips a lot of teams up), how the web list relates to the Mobile, API, and LLM lists, and something most articles skip entirely: how to detect and block each category at runtime, not just during development. No vendor knowledge required to follow it.

Table of Contents

• What Is the OWASP Top 10?
• The OWASP Top 10 2025 List: Every Vulnerability Explained
• What Changed: OWASP Top 10 2021 vs 2025
• OWASP Top 10 vs Mobile, API, and LLM Top 10
• How to Protect Against the OWASP Top 10 at Runtime
• OWASP Top 10 Compliance Checklist
• Frequently Asked Questions

What Is the OWASP Top 10?

The OWASP Top 10 is a standard awareness document that ranks the ten most critical security risks to web applications. It is maintained by the Open Worldwide Application Security Project (OWASP), a nonprofit community of security practitioners, and it is built from data: vulnerability findings contributed by security vendors and organizations, combined with a community survey for emerging risks that data alone does not yet capture.

The list is updated roughly every three to four years. The 2025 edition is the eighth version since the project began in 2003, following the well-known 2017 and 2021 editions. Each entry is a category of related weaknesses rather than a single bug, and most categories map to one or more Common Weakness Enumerations (CWEs).

It helps to keep three terms separate. A vulnerability is the weakness itself, such as an unvalidated input field. A threat is the actor or event that could exploit it. Risk is the combination of the two: how likely exploitation is, multiplied by the business impact if it succeeds. The OWASP Top 10 is fundamentally a prioritized view of risk, which is why it makes a strong starting point for a security program but a poor substitute for one.

The OWASP Top 10 2025 List: Every Vulnerability Explained

Here is the complete OWASP Top 10 2025, in official order, with what each category covers and where it can be addressed at runtime. The deep remediation details for the most exploited categories live in the dedicated guides linked throughout.

A01:2025 Broken Access Control

Broken access control occurs when an application fails to enforce what authenticated users are allowed to do. The result is users reading or modifying data that does not belong to them, or escalating their privileges. The most common pattern is Insecure Direct Object Reference (IDOR), where changing an identifier like /api/orders/1042 to /api/orders/1043 returns another user’s record because the server never checks ownership.

It remains the number one risk in 2025, and it now absorbs Server-Side Request Forgery (SSRF), which was its own category in 2021. OWASP folded SSRF in because coercing a server into making requests it should not make is itself an access control failure. For the full taxonomy of how these attacks are carried out, see our guide to web application attacks.

A02:2025 Security Misconfiguration

Security misconfiguration covers insecure defaults, incomplete setups, and exposed surface across the entire stack: web servers, frameworks, databases, cloud services, and containers. Typical examples are default admin credentials left active, debug endpoints or verbose stack traces exposed in production, unnecessary ports left open, and overly permissive CORS policies.

This category rose from fifth place in 2021 to second in 2025, reflecting how much of modern risk comes from how systems are assembled and deployed rather than from the application code itself. Cloud environments amplify it: a single permissive IAM role or public storage bucket can expose an entire dataset.

A03:2025 Software Supply Chain Failures

Software supply chain failures is the 2025 evolution of the 2021 category “Vulnerable and Outdated Components,” broadened well beyond known CVEs. It now covers the whole chain of trust: compromised build tools, malicious or typo-squatted dependencies, insecure CI/CD pipelines, and unverified third-party artifacts.

The reason for the expansion is that attackers increasingly target the things you depend on rather than the code you wrote. Log4Shell (CVE-2021-44228) showed how one logging library could expose millions of applications, and incidents like SolarWinds showed that the build pipeline itself is a target. Defending it relies on Software Composition Analysis (SCA) and a Software Bill of Materials (SBOM) so you know exactly what you ship.

A04:2025 Cryptographic Failures

Cryptographic failures happen when sensitive data is not properly protected: transmitting credentials or financial data in cleartext, using deprecated algorithms such as MD5 or SHA-1 for password hashing, hardcoding or co-locating encryption keys with the data they protect, or failing to enforce TLS everywhere. The consequences are leaked credentials, exposed personal records, and direct violations of regulations like PCI DSS and GDPR. The category dropped from second in 2021 to fourth in 2025, not because it matters less, but because misconfiguration and supply chain risk climbed.

A05:2025 Injection

Injection occurs when untrusted input is sent to an interpreter as part of a command or query and gets executed as code instead of treated as data. SQL injection, NoSQL injection, OS command injection, and cross-site scripting (XSS) all fall in this category. A classic SQL injection looks like this:

// VULNERABLE: user input concatenated into the queryconst query = `SELECT * FROM users WHERE id = '${req.query.id}'`;// Attacker sends ?id=' OR '1'='1  -> returns every row// SECURE: parameterized query separates code from datadb.query('SELECT * FROM users WHERE id = ?', [req.query.id]);

Injection has been on every OWASP list for over two decades, but it dropped from third in 2021 to fifth in 2025 as frameworks made parameterized queries and automatic output encoding the default. It is still one of the most reliably exploitable categories. For detection and blocking at the query level, see SQL injection detection, and for document databases, NoSQL injection.

A06:2025 Insecure Design

Insecure design refers to flaws in architecture and missing security controls that cannot be fixed by writing cleaner code. A perfectly implemented feature can still be insecure if the design never accounted for abuse. Examples include a password reset flow that reveals whether an email is registered, a file upload with no server-side validation, or an API with no rate limiting. The defense is proactive: threat modeling during design, using frameworks like STRIDE, and security review before code is written.

A07:2025 Authentication Failures

Authentication failures, renamed from “Identification and Authentication Failures” in 2021, covers weaknesses that let attackers compromise identity: credential stuffing against accounts with no rate limiting, weak or default passwords, exposed session identifiers, and missing or bypassable multi-factor authentication. Because these attacks are high-volume and automated, controls like rate limiting, brute-force detection, and strong session management are central to defending the category.

A08:2025 Software or Data Integrity Failures

This category covers code and data that are trusted without verifying their integrity: auto-update mechanisms that do not check signatures, deserialization of untrusted data, or CI/CD processes that deploy unverified artifacts. It overlaps with supply chain risk but focuses specifically on the failure to validate that code and data have not been tampered with before they are used.

A09:2025 Security Logging and Alerting Failures

Renamed from “Security Logging and Monitoring Failures,” this category is about not seeing attacks. When authentication failures, access control violations, and blocked attempts are not logged, or are logged but never trigger an alert, breaches go undetected for weeks or months. The 2025 rename toward “alerting” emphasizes that collecting logs is not enough; someone or something has to act on them in time to matter.

A10:2025 Mishandling of Exceptional Conditions

Mishandling of exceptional conditions is a new category in 2025. It covers what happens when an application handles errors and unexpected states incorrectly: failing open instead of failing closed, leaking sensitive details in error messages and stack traces, or continuing execution in an undefined state after an exception. These are not always exploitable on their own, but they routinely turn a minor fault into a security incident by exposing internals or bypassing a control that assumed the happy path.

What Changed: OWASP Top 10 2021 vs 2025

Before the comparison, one clarification that saves a lot of confusion: there is no “OWASP Top 10 2024.” The official successor to the 2021 list is the 2025 edition. If you see references to a 2023 list, those almost always point to the separate OWASP API Security Top 10, which is a different project.

Four structural changes define the move from 2021 to 2025. SSRF stopped being its own entry and was merged into Broken Access Control. Security Misconfiguration climbed from fifth to second. “Vulnerable and Outdated Components” was broadened and renamed Software Supply Chain Failures. And a brand-new category, Mishandling of Exceptional Conditions, entered at number ten. Injection and Cryptographic Failures both slid down the ranking as a result.

The underlying theme is a shift from individual coding mistakes toward systemic issues: how software is configured, assembled from dependencies, and operated. That is worth keeping in mind when you decide where to invest defensive effort.

OWASP Top 10 vs Mobile, API, and LLM Top 10

The “OWASP Top 10” most people mean is the web application list covered above. But OWASP maintains several parallel Top 10 lists for different application types, and using the right one matters because the risks differ by surface.

If you are securing APIs, the web Top 10 is necessary but not sufficient; pair it with API-specific testing and controls covered in our guides to API security testing and the API security checklist. For mobile apps, the device and client threat model is different enough that it has its own list, which we break down in mobile app security best practices. And if you are shipping LLM features, the OWASP Top 10 for LLM Applications puts prompt injection at the top, a risk that does not exist in the classic web list at all.

How to Protect Against the OWASP Top 10 at Runtime

Most OWASP guidance, correctly, focuses on prevention: find and fix vulnerabilities before they ship. Static analysis (SAST) traces injection and weak crypto in source code, dynamic testing (DAST) probes the running app for access control and misconfiguration issues, and Software Composition Analysis (SCA) flags vulnerable dependencies. Our SAST vs DAST vs IAST vs RASP comparison breaks down how those detection methods fit together, and for a category-by-category remediation walkthrough see how to detect and fix application security vulnerabilities.

The gap is the window between when a vulnerability exists in production and when it is fixed. In my experience, teams that get breached rarely lacked a scanner. They lacked anything watching the application once it was live. Patching takes time, and zero-days have no patch at all. Runtime protection closes that window by operating inside the application, observing actual execution, and responding to attacks as they happen. This is the Application Detection and Response (ADR) approach: in-process instrumentation that sees the real query, the real outbound request, the real exception, with full code context rather than only inspecting HTTP traffic at the edge. It complements a WAF or API gateway; it does not replace them.

Not every OWASP category is equally addressable at runtime. Design flaws (A06) have to be fixed in design. The table below is an honest map of where runtime detection and response adds a meaningful layer versus where build-time and design-time controls do the heavy lifting.

The pattern is consistent: runtime protection is strongest on the input- and behavior-driven categories, especially Injection (A05), SSRF within Broken Access Control (A01), authentication abuse (A07), and logging and alerting (A09), and it acts as a safety net for supply chain and integrity risks while you patch. Tools like ByteHide App Runtime implement this ADR approach across server, mobile, and APIs, adding a runtime detection-and-response layer on top of your existing testing pipeline.

OWASP Top 10 Compliance Checklist

Use this as a practical starting point. Each item maps to one or more 2025 categories, and the last note says whether a runtime layer helps once code is in production.

• Enforce least-privilege access control and verify ownership on every object reference (A01). Runtime: helps via anomalous-access detection.
• Validate user-supplied URLs and block requests to internal ranges and cloud metadata (A01 / SSRF). Runtime: strong.
• Harden configurations: remove defaults, disable debug in production, restrict CORS, close unused ports (A02). Runtime: detects drift.
• Maintain an SBOM and run SCA continuously in CI; verify artifact signatures (A03 / A08). Runtime: blocks exploitation as a safety net.
• Encrypt data in transit and at rest; use bcrypt or Argon2 for passwords; rotate keys (A04). Runtime: detects cleartext.
• Use parameterized queries and automatic output encoding everywhere (A05). Runtime: strong.
• Threat model new features before building them (A06). Runtime: not applicable.
• Rate-limit authentication, enforce MFA, and detect credential stuffing (A07). Runtime: strong.
• Log security events and route them to alerts that someone acts on (A09). Runtime: strong.
• Fail closed, sanitize error output, and handle exceptions explicitly (A10). Runtime: detects abnormal behavior.

No single item is sufficient on its own. The value is in combining secure design, build-time testing, and runtime protection so that a miss at one layer is caught at another.

Frequently Asked Questions

What is the OWASP Top 10 2025?

The OWASP Top 10 2025 is the current edition of OWASP’s standard awareness document ranking the ten most critical security risks to web applications. Released in November 2025, it is the eighth version and the first update since 2021. It keeps Broken Access Control at number one, moves Security Misconfiguration to second, and adds two structural changes: Software Supply Chain Failures and a new category, Mishandling of Exceptional Conditions.

What’s the difference between the OWASP Top 10 2021 and 2025?

The biggest changes are that SSRF was merged into Broken Access Control, Security Misconfiguration rose from fifth to second, “Vulnerable and Outdated Components” was broadened and renamed Software Supply Chain Failures, and Mishandling of Exceptional Conditions joined as a new tenth category. Injection and Cryptographic Failures both dropped in rank. The overall shift is from individual coding bugs toward systemic configuration, dependency, and operational risks.

Is there an OWASP Top 10 2024?

No. There is no OWASP Top 10 2024. The official update to the 2021 web application list is the 2025 edition. References to a “2023” list usually point to the separate OWASP API Security Top 10, which is a different project with its own numbering.

How often is the OWASP Top 10 updated?

Roughly every three to four years. Major editions were published in 2017, 2021, and 2025. Updates are driven by contributed vulnerability data plus a community survey for emerging risks that the data has not yet caught up to.

What is the most common OWASP vulnerability?

Broken Access Control. It ranked number one in both 2021 and 2025, appearing in a large share of tested applications. In 2025 it also absorbs Server-Side Request Forgery, making it an even broader category.

Is the OWASP Top 10 a compliance standard?

Not by itself. It is an awareness and prioritization document, not a certification. However, it is widely referenced by standards and frameworks such as PCI DSS and is commonly used as a baseline for security testing, developer training, and audit scoping.

Can you protect against the OWASP Top 10 at runtime?

Partly, and it depends on the category. Runtime protection through an Application Detection and Response (ADR) approach is strongest for input- and behavior-driven risks like injection, SSRF, authentication abuse, and logging gaps, and it acts as a safety net for unpatched components. Design flaws still have to be fixed in design, so runtime protection complements rather than replaces secure coding and testing.

The OWASP Top 10 is not a checklist you complete once. It is a snapshot of how application risk is shifting, and the 2025 edition makes that shift explicit: the weak points are increasingly in how software is configured, assembled, and operated, not only in the code a developer writes by hand. Teams that treat the list as a shared language for risk, and back it with controls across design, build, and runtime, get far more out of it than teams that treat it as a box to tick.