Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. In simpler terms, users can access data or functionality they shouldn't have access to.

Security Misconfiguration is the vulnerability class that arises when a web application, or any layer it depends on, is deployed with insecure settings: options left at unsafe defaults, security controls that were never switched on, permissions that are too broad, sample or administrative components left installed, or verbose behaviour that leaks internal detail. It is not one specific bug in your source code—it is the accumulated gap between how a system can be hardened and how it was actually shipped.

Software Supply Chain Failures occur when an attacker compromises any of the people, code, tools, or infrastructure that a piece of software depends on before it reaches production—so that malicious or vulnerable code is delivered through channels the victim already trusts. The application team may write flawless code and still ship a backdoor, because the compromise lives in a dependency, a build server, a signing key, a container base image, or a script loaded from a third-party CDN.

Cryptographic Failures (formerly known as Sensitive Data Exposure) occur when applications fail to adequately protect sensitive data through proper encryption, hashing, or other cryptographic controls. This vulnerability class encompasses failures related to cryptography that often lead to exposure of sensitive data.

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Insecure Design is a broad category describing weaknesses that originate in the design and architecture of an application rather than in a defective line of code. It represents a missing or ineffective security control: a threat the system was never designed to resist, a business workflow that can be abused as intended, or a trust assumption that does not hold once a real adversary is involved.

Authentication Failures is the 2025 edition's name for the category that covers every way an application fails to reliably confirm who is making a request and to keep that confirmation trustworthy for the life of a session. It is the direct evolution of A07:2021 — Identification and Authentication Failures, which was itself the 2021 renaming and re-scoping of A2:2017 — Broken Authentication.

Software and Data Integrity Failures occur when code, infrastructure, or data is trusted without verifying that it has not been tampered with. The core question this category asks is simple: "How do you know that the software you are running, and the data you are about to act on, are exactly what you expect—and not something an attacker substituted along the way?

Logging & Alerting Failures occur when an application does not record security-relevant events with enough detail, does not turn those records into timely, actionable alerts, or does not act on the alerts it produces. Unlike most categories in the Top 10, this is not a flaw an attacker exploits to break in — it is a detection and response gap that lets every other attack proceed unnoticed, for longer, and with a worse outcome.

Mishandling of Exceptional Conditions is the security weakness that arises when software handles errors, exceptions, and unusual or edge-case states in ways that create an exploitable gap. The underlying weakness is catalogued as CWE-755: Improper Handling of Exceptional Conditions, and it pulls in a family of related weaknesses: information leakage through error messages (CWE-209), failure to fail securely (CWE-636), improper cleanup on the error path (CWE-460), detecting an error but doing nothing about it (CWE-390), and uncaught exceptions that terminate the process (CWE-248).