OWASP Top 10:2025 — The New Release, Category by Category
The OWASP Top 10:2025 Release Candidate was published on November 6, 2025 at OWASP Global AppSec DC. It is the current authoritative reference and supersedes the 2021 edition. Broken Access Control stays at #1, Security Misconfiguration jumps from #5 to #2, Software Supply Chain Failures is a new A03 (expanding 2021's "Vulnerable and Outdated Components"), SSRF is folded into A01, and Mishandling of Exceptional Conditions is a brand-new A10. Eight categories were derived from data on ~2.8 million applications; two were promoted by community survey.
What changed and why it matters
The 2025 list reflects four years of telemetry and a clear shift in industry concern: away from individual code-level bugs and toward systemic failures in how software is built, distributed, and operated.
OWASP analyzed approximately 175,000 CVE-to-CWE mappings across 589 distinct CWEs (up from ~400 in 2021) covering roughly 2.8 million tested applications. Eight categories were derived directly from that dataset; two — Software Supply Chain Failures and Mishandling of Exceptional Conditions — were promoted via the community survey, where 50% of respondents ranked supply chain as their #1 concern.
Two practical consequences:
- Compliance frameworks will lag. Most SOC 2, PCI DSS, and ISO 27001 mappings still reference 2021. Plan for a 6–18 month transition window.
- Detection tooling is partially behind. Static and dynamic scanners that aligned their rule packs to 2021 categories need re-mapping — especially for supply chain (A03) and exceptional conditions (A10), which previously had no first-class home on the list.
The 2025 release is currently a Release Candidate. OWASP traditionally finalizes within 3–6 months of the RC announcement. Categories and rankings are unlikely to change; descriptions and CWE mappings may be refined.
A01:2025 — Broken Access Control
Position change: Unchanged at #1. 40 CWEs mapped.
Access control failures remain the most prevalent class of vulnerability in tested applications. The biggest structural change for 2025: SSRF (CWE-918) is now folded into A01 instead of being a standalone category. OWASP's rationale is that SSRF is fundamentally a server-side authorization failure — the application is making a request the user should not be able to coerce it into making.
Common manifestations:
- IDOR and BOLA (object-level authorization gaps)
- Missing function-level checks on POST/PUT/DELETE endpoints
- JWT or cookie tampering for privilege escalation
- CORS misconfiguration enabling unauthorized origins
- URL parameter tampering and forced browsing
- SSRF reaching cloud metadata endpoints (IMDSv1, GCP/Azure metadata)
Fix guidance. Deny by default. Centralize authorization in a single enforcement layer. Validate record ownership server-side on every request. Disable IMDSv1, enforce IMDSv2 with hop limit 1 on AWS.
Learn deeper: /learn/idor, /learn/idor-vertical, /learn/ssrf-cloud-metadata.
A02:2025 — Security Misconfiguration
Position change: Up from #5 (2021) to #2. 16 CWEs mapped.
The biggest mover on the list. OWASP reports that 100% of tested applications had at least one form of misconfiguration, with a 3.00% average incidence rate per CWE. The promotion reflects the increased complexity of modern stacks — Kubernetes, service meshes, IaC, multi-cloud — and the high cost of getting any single layer wrong.
Common manifestations:
- Default credentials left in place (admin consoles, message brokers, databases)
- Public S3/GCS buckets and over-permissive IAM
- Verbose error messages exposing stack traces and framework versions
- Missing security headers (CSP, HSTS, X-Content-Type-Options)
- Unnecessary services and debug endpoints reachable in production
- Inconsistent hardening across environments
Fix guidance. Establish a repeatable hardening process with automated drift detection (CIS Benchmarks, Open Policy Agent, conftest). Centralize error handling. Use short-lived federated credentials instead of long-lived secrets baked into images or config files.
A03:2025 — Software Supply Chain Failures (NEW)
Position change: New category at #3. Expands 2021's "Vulnerable and Outdated Components" (A06:2021). 5 CWEs mapped.
The headline change of 2025. The old category was narrow — "is your library version old?" The new one covers the full lifecycle: dependencies, transitive dependencies, build pipelines, CI/CD secrets, package registries, code-signing infrastructure, and distribution channels.
Voted #1 in the community survey by exactly 50% of respondents. Despite having the lowest occurrence rate in the testing dataset, OWASP notes A03 has the highest average weighted impact of any 2025 category — when supply chain attacks succeed, they tend to be catastrophic.
Notable incidents shaping the 2025 framing:
- SolarWinds (2019) — compromised vendor reached ~18,000 organizations
- XZ Utils backdoor (CVE-2024-3094) — multi-year social engineering of an OSS maintainer; nearly shipped a backdoored sshd to Debian/Fedora stable
- Bybit (2025) — supply chain compromise in wallet tooling, ~$1.5B theft
- Shai-Hulud (2025) — first self-propagating npm worm; reached 500+ package versions before takedown, harvested npm tokens via post-install scripts to re-publish malicious versions
Common manifestations:
- Unsigned package updates and absent integrity verification
- CI/CD pipelines with broader privileges than the systems they deploy
- Typosquatting and dependency confusion in package registries
- Long-lived registry tokens stored in plaintext on developer workstations
- Untracked transitive dependencies without an SBOM
- "Trust the registry" pattern — pulling latest tag without pinning hash
Fix guidance. Maintain a current SBOM (CycloneDX or SPDX). Pin dependencies by hash, not version range. Verify signatures (Sigstore/Cosign for containers, npm provenance for JS, PEP 740 for Python). Harden CI/CD with least-privilege OIDC federation. Stage rollouts via canary deployments. Treat your developer workstations and build servers as production targets.
A04:2025 — Cryptographic Failures
Position change: Down two spots from #2 (2021) to #4. 32 CWEs mapped.
Renamed from "Sensitive Data Exposure" in 2017 to "Cryptographic Failures" in 2021, the category keeps its 2021 name. The 2025 update narrows focus to crypto-specific weaknesses rather than the broader concept of "data leakage."
Common manifestations:
- Weak algorithms (MD5, SHA-1, DES, RC4) still in production
- Hardcoded keys committed to repositories or container images
- Reused IVs, ECB mode, missing authenticated encryption
- Self-signed or unvalidated certificates accepted in TLS clients
- Password hashing with fast functions (SHA-256, MD5) instead of adaptive ones
- Predictable random number generation for tokens and session IDs
Fix guidance. TLS 1.2+ only with forward-secret cipher suites. Argon2id, scrypt, or PBKDF2-HMAC-SHA-512 for password hashing. Authenticated encryption (AES-GCM, ChaCha20-Poly1305) for symmetric crypto. Keys in HSMs or KMS, never in source. Start your post-quantum migration planning now — NIST recommends transitioning critical systems by 2030.
Learn deeper: /learn/jwt-vulnerabilities, /learn/jwt-weak-secret.
A05:2025 — Injection
Position change: Down two spots from #3 (2021) to #5. 38 CWEs mapped.
Injection has continued its multi-decade decline thanks to safer-by-default frameworks (parameterized queries, ORMs, React/Vue auto-escaping). It remains highly impactful when it does occur — OWASP reports 14,000+ SQL injection CVEs and 30,000+ XSS CVEs in the analyzed dataset.
Sub-classes still firing in production:
- SQL Injection — low frequency, high impact
- Cross-Site Scripting (XSS) — high frequency, lower per-instance impact
- Command Injection — high impact, often in legacy admin tools
- LDAP Injection — niche but persistent in enterprise auth flows
- NoSQL Injection — Mongo, Couchbase operator injection
- Expression Language Injection — Spring SpEL, OGNL, Thymeleaf
- ORM Injection — Hibernate HQL, Sequelize raw queries
Fix guidance. Parameterized queries everywhere; if you can't parameterize (e.g., dynamic ORDER BY), use a strict allowlist. Server-side input validation. Combine SAST + DAST + IAST — each catches a different shape of injection. Once you confirm one of these classes, score it with our free CVSS v4.0 calculator to set the right remediation severity.
Learn deeper: /learn/sqli, /learn/xss, /learn/command-injection, /learn/ssti.
A06:2025 — Insecure Design
Position change: Down two spots from #4 (2021) to #6. No reduction in importance — A02 and A03 just pushed up.
Insecure design covers architectural and process failures that cannot be patched at the code level. The 2025 framing emphasizes three pillars: requirements/resource management, secure design methodology, and a documented secure development lifecycle.
Common manifestations:
- Missing or skipped threat modeling for critical flows (auth, billing, RBAC)
- Trust boundary violations (client-supplied data treated as authoritative)
- Insufficiently protected credential stores (CWE-522)
- Unrestricted file uploads by design (CWE-434)
- Privilege management baked into business logic instead of a central authorization layer
- "We'll add rate limiting later" — recurring pattern in growth-phase startups
Fix guidance. Threat-model every new feature touching auth, money, or PII. Maintain a library of secure design patterns the team reuses. Write unit and integration tests that target abuse cases, not just happy paths. Get an AppSec professional into design reviews, not just code reviews.
A07:2025 — Authentication Failures
Position change: Unchanged at #7. Renamed from "Identification and Authentication Failures" (2021) to "Authentication Failures" — the 36 mapped CWEs are predominantly authentication, not identification, weaknesses.
Common manifestations:
- Hard-coded passwords and API keys (CWE-259, CWE-798)
- Session fixation (CWE-384)
- Improper authentication logic (CWE-287) — typically authentication bypasses via header manipulation, race conditions, or logic gaps
- Certificate validation bypasses (CWE-297)
- Missing or weak MFA on privileged accounts
- Predictable session IDs, no rotation post-login
- Account enumeration via timing or response differences
Fix guidance. MFA on every privileged account, ideally phishing-resistant (FIDO2/WebAuthn). NIST SP 800-63b-aligned password policies — no forced rotation, breach-list checks, no composition rules. Server-side session managers with high-entropy IDs. Rate-limit failed logins; lock or step-up after threshold.
Learn deeper: /learn/jwt-alg-none, /learn/session-overview, /learn/csrf.
A08:2025 — Software or Data Integrity Failures
Position change: Unchanged at #8. Scope narrowed — the supply chain portion split out to A03:2025. A08 now focuses tightly on integrity verification at the code and data level: signature validation, deserialization, and CI/CD pipeline integrity within your own environment.
Common manifestations:
- Inclusion of functionality from untrusted control spheres (CWE-829)
- Deserialization of untrusted data (CWE-502) — Java, .NET, Python pickle, Ruby Marshal
- Auto-updates without signature validation (CWE-494)
- Modification of dynamically-determined object attributes (CWE-915) — including mass assignment
- Loading scripts from untrusted CDNs without subresource integrity
Fix guidance. Verify digital signatures on every executable artifact you ingest. Restrict deserialization to allowlisted types — never deserialize untrusted input with pickle.loads, unserialize, ObjectInputStream, or Marshal.load. Subresource integrity hashes on every external script. Code review every change touching CI/CD configuration.
Learn deeper: /learn/mass-assignment.
A09:2025 — Security Logging and Alerting Failures
Position change: Unchanged at #9. Renamed from "Logging and Monitoring Failures" — OWASP wanted to emphasize that logging without alerting is just expensive disk usage.
Common manifestations:
- High-value events (logins, failed logins, privilege changes, financial transactions) not logged
- Logs without enough context for forensic analysis (no user ID, no request correlation)
- Log injection (CWE-117) enabling tampering or alert evasion
- Sensitive data (passwords, tokens, PII) written into logs (CWE-532)
- No alerting on auth anomalies, privilege escalations, or data exfiltration patterns
- Append-only / tamper-evident storage missing — attackers wipe logs post-compromise
Fix guidance. Define the security-relevant event catalog up front (login success/failure, privilege change, MFA enrollment, password reset, admin action). Centralize logs in an append-only store. Alert on patterns, not just thresholds — five failed logins is noise, five failed logins followed by a successful one from a new geography is signal. Run tabletop exercises against your alerting playbooks.
A10:2025 — Mishandling of Exceptional Conditions (NEW)
Position change: Brand-new category at #10. 24 CWEs mapped. Promoted from the community survey.
The other major new entry in 2025. A10 is conceptually adjacent to A06 (Insecure Design) but focuses specifically on what happens when something goes wrong at runtime: a missing parameter, an upstream timeout, a malformed input, a database deadlock. Failing open, leaking error details, leaving resources locked, or losing transaction atomicity all land here.
Common manifestations:
- "Failing open" — security checks throw and the catch block returns success (CWE-636)
- Verbose error pages exposing stack traces, framework versions, query fragments (CWE-209)
- Null pointer dereference enabling DoS (CWE-476)
- Missing parameter handling causing crashes or default-on behavior (CWE-234)
- Multi-step transactions interrupted mid-flow without rollback — financial state corruption
- Resource leaks from un-released handles in exception paths (DoS via exhaustion)
- Improper handling of insufficient privileges (CWE-274) — operation proceeds with degraded checks
Fix guidance. Catch exceptions at the layer where they occur, not at a top-level catch-all. Fail closed: any auth/authz/integrity check that throws must default to denial. Centralize error responses — return generic messages to clients, log details server-side. Use transactional patterns with explicit rollback. Add rate limits, resource quotas, and timeouts at every external boundary. Monitor error-rate spikes; they often precede or accompany attacks.
How the 2025 list maps back to 2021
| 2025 Category | 2021 Equivalent | Change |
|---|---|---|
| A01:2025 Broken Access Control | A01:2021 + A10:2021 (SSRF folded in) | Absorbed SSRF |
| A02:2025 Security Misconfiguration | A05:2021 | Up 3 positions |
| A03:2025 Software Supply Chain Failures | A06:2021 (Vulnerable Components) | Expanded scope, renamed |
| A04:2025 Cryptographic Failures | A02:2021 | Down 2 |
| A05:2025 Injection | A03:2021 | Down 2 |
| A06:2025 Insecure Design | A04:2021 | Down 2 |
| A07:2025 Authentication Failures | A07:2021 | Renamed |
| A08:2025 Software or Data Integrity Failures | A08:2021 | Scope narrowed (supply chain → A03) |
| A09:2025 Security Logging and Alerting Failures | A09:2021 | Renamed |
| A10:2025 Mishandling of Exceptional Conditions | — | New |
| — | A10:2021 SSRF | Merged into A01:2025 |
Adoption recommendations
For most security and engineering teams, the practical work is:
- Re-map your AppSec program — update internal risk registers, threat-model templates, and security-testing checklists to reference 2025 categories. Keep a 2021↔2025 crosswalk for audits.
- Prioritize A03 controls now. SBOM, signed artifacts, hardened CI/CD, dependency hash pinning. This is the category most likely to produce a public incident in 2026.
- Audit your error-handling paths for A10. Run failure-mode reviews on the auth and billing flows specifically — most "failing open" bugs we see in the wild started as a try/except that swallowed an exception.
- Update detection rules. SAST and DAST tooling should map findings to A03 and A10 explicitly. If your scanner still reports "Vulnerable Components" or doesn't have an A10 bucket, raise it with the vendor.
- Don't wait for the final release. OWASP RCs rarely shift in ranking. Treat 2025 as the working standard today.
Where BreachVex fits
BreachVex is pre-launch, so we'll keep this short and honest. Our pipeline targets the categories that automation can verify reliably: A01 (access control), A05 (injection), A02 (misconfiguration), and parts of A04 (cryptographic protocol issues at the network edge). For A03 supply chain and A09 alerting, automated external testing has limited reach — those require pipeline access and observability data we don't have from a black-box scan.
Expect 2025-aligned reporting in our SARIF and PDF outputs at launch. The category mappings in our finding metadata will reference both 2021 and 2025 throughout the transition.