Injection

A01:2025Broken Access Control

Access control decides who may do what. It breaks when an application checks identity but never properly re-checks authority on the server for the specific action and record being requested. Because the rules live in application logic rather than in a single enforceable boundary, gaps are easy to introduce and hard to spot in review. In the 2025 edition this category also absorbed server-side request forgery, on the reasoning that tricking a server into making a request on your behalf is itself a failure to constrain what the server is permitted to reach.

A02:2025Security Misconfiguration

Software is usually far more permissive out of the box than it needs to be in production, and modern systems have an enormous amount of configuration surface: frameworks, containers, orchestrators, cloud services, identity providers, and CI systems all carry their own defaults. This category covers the security you never switched on, the sample content you never removed, and the environment differences nobody reconciled. It climbed to second place in the 2025 edition, reflecting how much of a deployment's risk now sits in configuration rather than in code.

A03:2025Software Supply Chain Failures

New in the 2025 edition, and a broadening of what used to be framed narrowly as vulnerable and outdated components. The point is that you inherit risk from everything involved in producing and delivering your software, not just from the libraries you import: package registries, build systems, CI/CD runners, base images, plugins, and the third-party services your build trusts. An attacker who compromises any of those can have malicious code signed and shipped through your own legitimate release process.

A04:2025Cryptographic Failures

This category is about failures to protect data that deserves protection, whether in transit, at rest, or in backups and logs. The failures are rarely broken mathematics; they are missing encryption, obsolete algorithms, reused or hard-coded keys, weak randomness, and passwords stored with fast hashes. The first question is always a data-classification question: what are you holding, does it need protection, and for how long.

A06:2025Insecure Design

Some weaknesses cannot be patched because nothing is technically broken — the system was specified to behave that way. Insecure design covers missing or inadequate security controls in the design itself: a workflow that can be replayed, a trust assumption that does not hold, a recovery mechanism weaker than the thing it protects. A perfect implementation of a flawed design is still insecure, which is why this category is addressed with threat modelling and reference architectures rather than with scanners.

A07:2025Authentication Failures

Authentication establishes who is making a request, and session management preserves that answer across subsequent requests. This category covers weaknesses in both: credential stuffing and brute force that go unthrottled, factors that can be phished or relayed, and sessions whose tokens are predictable, long-lived, or never invalidated. Because credentials are the most consistently attacked part of any application, small gaps here tend to be found and exploited quickly.

A08:2025Software or Data Integrity Failures

Integrity failures occur when a system accepts code, updates, or structured data without verifying that it is what it claims to be and has not been altered. Deserializing attacker-controlled objects is the classic technical case, because many deserializers can be steered into constructing dangerous types and reaching code execution. The broader case is any trusted-by-default input: an unsigned update, a script pulled from a third party, or a CI step that consumes an unverified artifact.

A09:2025Security Logging and Alerting Failures

This category is about not being able to tell that something happened. If security-relevant events are not recorded, or are recorded somewhere nobody watches, an intrusion continues until an outsider notices. The 2025 edition renamed the category to emphasise alerting rather than passive monitoring: the failure is usually not an absence of data but an absence of anything that turns data into a timely response. Logging failures also make incident response and forensics much harder after the fact.

A10:2025Mishandling of Exceptional Conditions

New in the 2025 edition. This category covers what a system does when something goes wrong: an unhandled error, an unexpected input, a dependency timing out, a resource running short. Failure is inevitable, so security depends on failing in a defined and safe direction. The common pattern is a control that silently degrades — an authorization or verification step that returns an error which is treated as success, or an exception path that skips cleanup and leaves the system in an inconsistent state.