Why the 2025 Release Is Significant

OWASP Top 10 editions have historically been fairly conservative β€” categories shuffle positions, some merge, some split. The 2025 edition is different in two ways that matter for security teams: a methodologically distinct new entry at A10, and a significant position change for Security Misconfiguration that reflects a real shift in how breaches are occurring.

The data set for 2025 drew from over 500,000 applications across 40+ contributing organisations β€” roughly double the data volume from the 2021 edition. The methodology for the new A10 category specifically required at least 24 CWEs with demonstrable real-world impact, which is a higher evidential bar than previous editions used for emerging categories.

Timing context: The 2021 edition was published in September 2021. The 2025 edition reflects the security landscape of 2023-2025 β€” a period that includes the rise of AI-generated code, the normalisation of cloud-native deployment, and a significant increase in supply chain attacks that fed into several categories.

The Full List: A01–A10 with Changes Called Out

  • A01 Broken Access Control β€” Stays at #1. Remains the most widespread vulnerability by data volume. IDOR, privilege escalation, and CORS misconfiguration all fall here.
  • A02 Security Misconfiguration β€” Jumps from #5 to #2. Default credentials, exposed admin panels, verbose error messages, cloud resource misconfigurations. See dedicated section below.
  • A03 Injection β€” Drops from #3 to #3 (unchanged). SQL, LDAP, OS command, and now LLM prompt injection all under this umbrella.
  • A04 Insecure Design β€” New in 2021, holds at #4. Architecture-level failures β€” threat modelling gaps, missing rate limiting, insecure design patterns baked into the system.
  • A05 Cryptographic Failures β€” Drops from #2 to #5. Weak algorithms, hardcoded keys, unencrypted sensitive data. Still critical but the data shows better adoption of TLS.
  • A06 Vulnerable and Outdated Components β€” Moves from #6 to #6 (holds). SCA coverage has improved, but the category remains high-volume due to transitive dependencies.
  • A07 Identification and Authentication Failures β€” Drops from #7 to #7. Credential stuffing, weak session management, missing MFA.
  • A08 Software and Data Integrity Failures β€” Moves from #8 to #8. Supply chain attacks, insecure CI/CD, unverified artifact integrity. See note below.
  • A09 Security Logging and Monitoring Failures β€” Holds at #9. Insufficient logging, no alerting on attack patterns, audit trail gaps.
  • A10 Exceptional Conditions β€” New entry replacing "Server-Side Request Forgery." See dedicated section below.

A02: Security Misconfiguration Jumps to #2 β€” Why?

The jump from #5 to #2 is the most dramatic position change in the 2025 edition, and it reflects something real: cloud infrastructure has made misconfiguration dramatically easier to do at scale. A developer creating an S3 bucket, a Kubernetes namespace, or a cloud function with default settings can inadvertently expose it to the internet in minutes. The attack surface for misconfiguration has exploded.

The 2025 data showed misconfiguration present in 90% of applications tested β€” the highest incidence rate of any category. The breaches it's enabling aren't subtle: publicly accessible S3 buckets with customer data, default admin credentials on management interfaces, Kubernetes dashboards exposed to the internet, verbose error messages leaking stack traces and connection strings to anonymous users.

Real pattern we see constantly: A containerised application deployed to Kubernetes with a Helm chart that has debug: true in the default values, exposing detailed error messages including SQL query strings and internal service URLs. The chart was forked from an open-source project three years ago and the developer never reviewed the defaults.

misconfiguration-examples.py Python β€” A02 patterns
# A02 pattern: verbose error response leaks internals
from flask import Flask
app = Flask(__name__)
app.config['DEBUG'] = True  # exposes debugger + stack traces

# What an attacker sees on a 500 error:
# sqlalchemy.exc.OperationalError: (psycopg2.errors.UndefinedTable)
# relation "users" does not exist
# [SQL: SELECT * FROM users WHERE id=1]
# Connection: postgresql://admin:[email protected]:5432/prod

# Fixed: environment-specific config
app.config['DEBUG'] = os.getenv('FLASK_DEBUG', 'false').lower() == 'true'
# And set FLASK_DEBUG=false in production β€” never true

A08: Vulnerable and Outdated Components Stays Critical

The headline message for A08 in 2025 is unchanged: organisations are still shipping production code with known CVEs in direct and transitive dependencies. The average enterprise application in the 2025 data set had 147 direct dependencies and over 1,200 transitive dependencies. At that scale, manual dependency management is not possible β€” you need automated SCA.

What's changed is the threat model. The 2021 discussion focused on CVEs and patch lag. The 2025 discussion adds supply chain tampering β€” dependencies that are themselves compromised, as discussed in A08 Software and Data Integrity Failures. The two categories are increasingly interrelated.

A10: Exceptional Conditions β€” The New Entry Explained

This is the most technically interesting addition to the 2025 list. "Exceptional Conditions" covers security failures that occur when applications encounter unexpected states β€” error conditions, edge cases, boundary conditions β€” and respond in ways that create security vulnerabilities.

The core pattern is: code that fails safely in the happy path but fails open in error conditions. A function that correctly enforces access control when it can reach the authorisation service, but grants access when that service returns an error or times out. An authentication check that returns false on invalid credentials but throws an exception on database errors β€” and the calling code treats exceptions as success.

exceptional-conditions.py Python β€” A10 antipattern
# A10 antipattern: exception swallowing that fails open
def check_admin_permission(user_id: int) -> bool:
    try:
        user = db.get_user(user_id)
        return user.role == "admin"
    except Exception:
        return True  # BUG: database error grants admin access to everyone

# Correct: fail closed β€” deny on exception
def check_admin_permission(user_id: int) -> bool:
    try:
        user = db.get_user(user_id)
        return user.role == "admin"
    except Exception as e:
        logger.error(f"Permission check failed for user {user_id}: {e}")
        return False  # fail closed: deny on error

OWASP identified 24 CWEs that contribute to this category, spanning exception handling failures, improper error handling that reveals sensitive information, and race conditions in security checks.

What Fell Off the List vs 2021

"Server-Side Request Forgery" (SSRF), which was A10 in the 2021 edition as a "forward-looking" category, was replaced by Exceptional Conditions. This doesn't mean SSRF is resolved β€” it's been absorbed into A01 Broken Access Control and A03 Injection depending on the attack pattern, reflecting how SSRF findings are classified in practice.

"XML External Entities" (XXE), which was A04 in 2017 and merged into Injection in 2021, continues to be captured under A03. The 2025 data showed XXE continuing to appear but at lower prevalence as organisations move away from XML-based APIs.

How the Data Methodology Changed

The 2025 methodology introduced a more rigorous standard for new category inclusion, requiring a minimum of 24 CWEs with documented real-world exploitation for any category to qualify. This is why the new A10 (Exceptional Conditions) represents a more evidence-based addition than some previous "forward-looking" categories.

The scoring model was also updated to weight "exploitability" and "impact" differently β€” previous editions used a simpler frequency-based ranking. The 2025 model incorporates both prevalence in the data set AND severity of confirmed real-world breaches attributed to each category, explaining some of the position changes that don't track directly with raw frequency data.

What This Means for Your Current Security Programme

If you're running a security programme that's mapped to OWASP 2021, here's the practical impact:

  • Elevate misconfiguration coverage: If your programme treats security misconfiguration as a lower-priority item, the data says it shouldn't be. Consider adding IaC scanning and cloud configuration auditing if you haven't already.
  • Add Exceptional Conditions to your code review checklist: Explicitly look for exception swallowing in security-critical functions, and verify that error handlers fail closed rather than open.
  • Update your SAST rule mappings: If your SAST findings are tagged to OWASP 2021 categories, update the mapping so exception-handling patterns route to A10 2025.
  • Refresh compliance documentation: If you're reporting OWASP coverage to clients, auditors, or a compliance framework, update the category references.

Mapping from 2021 to 2025

  • A01 Broken Access Control (2021) β†’ A01 Broken Access Control (2025) β€” same category, same position
  • A02 Cryptographic Failures (2021) β†’ A05 Cryptographic Failures (2025) β€” drops three positions
  • A03 Injection (2021) β†’ A03 Injection (2025) β€” same
  • A04 Insecure Design (2021) β†’ A04 Insecure Design (2025) β€” same
  • A05 Security Misconfiguration (2021) β†’ A02 Security Misconfiguration (2025) β€” jumps to #2
  • A06 Vulnerable and Outdated Components (2021) β†’ A06 (2025) β€” same
  • A07 Identification and Authentication Failures (2021) β†’ A07 (2025) β€” same
  • A08 Software and Data Integrity Failures (2021) β†’ A08 (2025) β€” same
  • A09 Security Logging and Monitoring Failures (2021) β†’ A09 (2025) β€” same
  • A10 SSRF (2021) β†’ replaced by A10 Exceptional Conditions (2025)

Practical Action Plan

  1. Audit your error handling for fail-open patterns. This is the new category β€” grep for bare except clauses and exception handlers that return success values.
  2. Run a misconfiguration scan. Use IaC scanning tools to check Terraform, CloudFormation, Helm charts, and Kubernetes manifests for default-insecure settings.
  3. Update your SAST rule set to include A10 patterns. Exception swallowing in security checks, missing error handling on authentication calls, and race conditions in permission checks are all now first-class findings.
  4. Review your OWASP coverage reports. Update category mappings in dashboards and compliance documents to reflect 2025 numbering.
  5. Prioritise A02 remediation in your backlog. If you have open security misconfiguration findings that have been deprioritised, the 2025 data supports elevating them.

Scan Against OWASP Top 10 2025

AquilaX SAST maps findings to OWASP 2025 categories including the new A10 Exceptional Conditions β€” so you can track coverage and report by risk category.

Start Free Scan