2026-09-26

The OWASP Top 10:2025, and What Actually Moved

OWASP's Top 10 is periodically rebuilt from real vulnerability data contributed across the industry, and the 2025 edition is a genuine reshuffle, not a rename of the 2021 list. Two categories are new outright, several risks moved several places, and Server-Side Request Forgery — a standalone entry in 2021 — no longer gets its own slot.

OWASP Top 10:2025 — What MovedRank change vs. the 2021 edition1A01 Broken Access ControlStill #1 — found in effectively every app tested#1–2A02 Security MisconfigurationUp from #5 in 2021#2▲3A03 Software Supply Chain FailuresNew category — highest average incidence rate#3NEW4A04 Cryptographic FailuresDown from #2 in 2021#4▼5A05 InjectionDown from #3 in 2021#5▼6A06 Insecure DesignDown from #4 in 2021#6▼7A07 Authentication FailuresWeak credentials, missing MFA#7–8A08 Software or Data Integrity FailuresUnverified CI/CD pipelines and updates#8–9A09 Security Logging & Alerting FailuresRenamed from "monitoring" to "alerting"#9–10A10 Mishandling of Exceptional ConditionsNew — replaces SSRF as a standalone category#10NEW

Generated with the Infographic Generator tool — built as SVG code, not a rendered image.

A01: Broken Access Control

Still #1, and still the most common finding in any audit. An endpoint verifies who a user is but never checks what they're allowed to touch — change an ID in a URL and you're reading someone else's record. 100% of applications tested carry some form of this. Enforce authorization on the server, on every request, never just in the UI.

A02: Security Misconfiguration

Jumped from #5 to #2. As more of the stack becomes configurable — cloud services, containers, Infrastructure as Code — there's more surface for a setting to be wrong: default credentials left in place, verbose errors leaking stack traces, storage left open. The fix is a hardened, repeatable deployment baseline, not a one-off patch.

A03: Software Supply Chain Failures

New for 2025, and it tested with the highest average incidence rate of any category. It broadens the old "vulnerable and outdated components" idea to cover the whole pipeline that builds, distributes, and updates your software — not just known-CVE dependencies, but the build tooling and update mechanisms around them. Every dependency and every build step is a trust decision that needs revisiting, not just a version number to bump.

A04: Cryptographic Failures

Down two spots from #2, but far from resolved: sensitive data exposed because it was never encrypted, or encrypted with something weak — outdated ciphers, hardcoded keys, TLS not enforced. Usually a design gap rather than a typo — it shows up when nobody decided what "sensitive" means for a system before it shipped.

A05: Injection

Down two spots from #3. SQL, NoSQL, OS command, LDAP — anywhere untrusted input gets concatenated into a query or command instead of passed as a parameter. It's the oldest name on this list and it's still here because it only takes one endpoint skipping parameterized queries.

A06: Insecure Design

Down two spots from #4. A deliberate category: some vulnerabilities aren't implementation bugs at all, they're missing or ineffective control design. No amount of careful coding fixes a feature that was never threat-modeled in the first place.

A07: Authentication Failures

Weak password rules, credential stuffing with no rate limiting, session tokens that don't expire or rotate, missing multi-factor authentication. Authentication is the one place where "good enough" isn't — it's the front door.

A08: Software or Data Integrity Failures

Trusting a CI/CD pipeline, plugin, or auto-update mechanism without verifying its integrity. This is how a single compromised upstream component turns into an incident that looks nothing like the original bug.

A09: Security Logging & Alerting Failures

Renamed from "monitoring" to "alerting" to make the point explicit: logs nobody acts on don't help. Without meaningful logging and alerting, the average breach isn't caught by the victim at all — it's reported by someone else, much later.

A10: Mishandling of Exceptional Conditions

New for 2025, and it replaces SSRF as a standalone category. It covers what happens when software meets an unusual or unpredictable condition and handles it badly — improper error handling, failing open instead of closed, ignoring the return value of a security check, logic errors that only surface under abnormal circumstances. The common thread: a security control that gets silently bypassed not because it was missing, but because the code around it didn't handle the edge case.

The instinct to treat this as a checklist to clear once is exactly what keeps most of these categories on the list release after release. It's worth revisiting deliberately — in design reviews, in code review, and before anything ships.