The OWASP Top 10 is a regularly updated awareness document that outlines the ten most critical security risks to web applications. Created by the Open Web Application Security Project (OWASP), it serves as a standard for developers, designers, and organizations to identify and mitigate common security weaknesses. The list is based on data from security experts and is used as a foundational resource for secure coding and compliance.
- Purpose: To educate and provide a starting point for securing web applications by highlighting the most critical security flaws.
- Methodology: The list is compiled from data submitted by security firms and researchers, with each risk category assessed using metrics like exploitability and impact.
- Content: Each risk category includes guidelines, examples, and best practices to help prevent attacks. For example, the 2025 list includes categories like “Broken Access Control,” “Security Misconfiguration,” and “Injection”.
- Adoption: The OWASP Top 10 is widely referenced and used as a baseline for compliance by various organizations, standards bodies, and security tools.
- How to use it: Developers and organizations can use the list to ensure their applications are protected against common vulnerabilities by incorporating the provided guidance into their development and testing processes.
What’s changed in the OWASP Top 10 for 2025
The upcoming 2025 edition of the OWASP Top 10 delivers a meaningful evolution in how software-security risk is being framed and prioritised. As indicated in the draft/intro material from OWASP, there are two new categories along with one consolidation of previously separate risk areas. The overall emphasis is clear: shift focus from symptoms (vulnerability outcomes) toward root causes (the underlying weakness), acknowledging that in today’s software ecosystems — with sprawling dependencies, cloud/service-config complexity, API/automation workflows — the old “top 10 checklist” exactly as before is no longer sufficient.
Below is a breakdown of each category change (position, scope, ranking) and what it tells us about the evolving risk landscape.
A01:2025 – Broken Access Control (remains #1)
Broken Access Control retains its top spot inside the 2025 list. According to OWASP’s data, on average 3.73% of applications tested had one or more of the 40 CWEs mapped to this category. The consolidation of adding Server-Side Request Forgery (SSRF) into this category is noted (“the dashed line … SSRF has been rolled into this category”).
Why this matters:
- Access control failures remain the most serious and prevalent application-security weakness, reflecting that despite decades of focus, many systems still allow “users doing what they shouldn’t”.
- By folding SSRF under access control, OWASP signals that SSRF is being regarded less as a standalone exotic category and more as an access-control abuse vector — i.e., access to internal resources, request paths, or privileged functionality.
- The 3.73% incidence rate may sound modest, but for risk-scoring purposes that means a significant chunk of applications are exposed.
A02:2025 – Security Misconfiguration (moves up to #2)
The risk category formerly lower in priority is now second. OWASP highlights that 3.00% of applications had one or more of the 16 CWEs in this category.
Significance:
- This change reflects the increasing complexity of modern software stacks: more configuration-driven behaviour (via cloud platforms, microservices, containers, feature toggles) means misconfiguration is becoming more frequent.
- Misconfiguration used to be treated as “ops”-level issue, but it is clearly now viewed as a first-class app-security risk — making sense that it rose in ranking.
- Organisations should note that “secure defaults” and configuration hygiene matter as much as code correctness.
A03:2025 – Software Supply Chain Failures (new/expanded)
This is either a new or heavily expanded category: OWASP notes this is an “expansion of A06:2021-Vulnerable and Outdated Components to include a broader scope of compromises occurring within or across the entire ecosystem of software dependencies, build systems, and distribution infrastructure.” Although the contributed test-data shows limited incidence in applications (likely due to difficulty in detection/testing), it “has the fewest occurrences in the data, but also the highest average exploit and impact scores from CVEs.”
Implications:
- Recognises that vulnerabilities are no longer just in your code-base, but in your tool-chain, dependencies, CI/CD pipelines, delivery mechanisms.
- “Supply chain” attacks are increasingly high-impact (log4j, dependency chaos, compromised containers, malicious packages). OWASP’s inclusion signals that defenders must treat this as a strategic risk, not a niche one.
- Testing for this domain is still catching up; security practitioners need to invest in dependency/third-party provenance, build-chain integrity, not just code scanning.
A04:2025 – Cryptographic Failures (drops to #4)
Previously ranked #2, this category has slid down to fourth place. On average, 3.80% of applications had one or more of the 32 CWEs in this category.
What’s behind the shift:
- While still very significant (failure in encryption, key-management, algorithm choice etc), its relative risk ranking dropped as other areas (misconfiguration, supply chain) have surged.
- Reflects maturity: more tooling, awareness, frameworks assist cryptography; whereas misconfig/config/chain risks are more diffuse and harder to automate.
A05:2025 – Injection (falls to #5)
Injection — long a staple of application-security awareness — falls two spots (from #3 in 2021 to #5 in 2025). OWASP points out that it remains heavily tested (greatest number of CVEs associated with its 38 CWEs). The ranking shift means others are now overtaking it in risk priority, though injection remains serious.
Take-aways:
- The fall may reflect both improved tooling/awareness (so fewer occurrences relative to others) and/or other risks rising faster.
- But injection is still a major risk category: it includes high-impact vulnerabilities (SQL injection) and high-frequency ones (XSS) — so dropping it in rank doesn’t mean “it’s safe”.
A06:2025 – Insecure Design (drops to #6)
Introduced in 2021, this category has slipped two places in 2025, as Security Misconfiguration and Software Supply Chain Failures leapfrog it.
Context:
- Insecure Design refers to flaws in the architecture, threat modelling, secure-by-design planning etc.
- The drop suggests that while design weaknesses persist, researchers/practitioners consider other categories more pressing in the “now” risk-landscape (configuration, supply chain).
- Encouragingly, its introduction (in 2021) reflects shift-left thinking (secure design), and although ranking dropped, it remains within Top 10 signalling its strategic importance.
A07:2025 – Authentication Failures (stays at #7)
This category retains its earlier position (#7) but takes a slight renaming from “Identification & Authentication Failures” to simply “Authentication Failures” to better reflect the 36 CWEs mapped.
Observations:
- The relative steadiness indicates moderate but not rising urgency compared to others.
- The industry’s use of standardised frameworks (OAuth2, OpenID Connect, SSO) appears to have beneficial effects in reducing some authentication failures.
- That said, many breaches still stem from broken authentication/credential misuse, so this remains a core defensive area.
A08:2025 – Software or Data Integrity Failures (remains #8)
This category remains in the eighth position. It focuses on failures to maintain integrity of software, code, data artifacts — and so it sits “at a lower level than Software Supply Chain Failures”.
Implications:
- The distinction drawn between “software/data integrity” and “supply chain failures” signals refined risk modelling.
- Ensuring integrity of binaries, configurations, data sets continues to be a foundational risk.
- It remains somewhat under-tested/under-represented in data, which means risk may be under-appreciated in many programmes.
A09:2025 – Logging & Alerting Failures (remains #9)
Previously called “Security Logging and Monitoring Failures”, this category now emphasises the alerting function (“Logging & Alerting Failures”).
Why this matters:
- Good logging with no alerting = minimal value for incident detection/response.
- The rename reflects a maturity in thinking: it isn’t just about collecting logs, it’s about making them actionable (alert, escalate, respond).
- This category will always be under-represented in standard vulnerability-data sets (because incident-monitoring deficiencies show up differently than code bugs) — hence the continued inclusion based on community survey rather than pure automated test-data.
A10:2025 – Mishandling of Exceptional Conditions (new category)
For 2025, this is a new category: focusing on improper error handling, logic-errors, fail-open conditions and other “exceptional condition” scenarios.
Significance:
- The introduction of this category is noteworthy: organisations often focus on “happy-path” behaviour, but ignoring exceptional/edge conditions (failures, unexpected inputs, resource exhaustion) creates real risk vectors.
- The explicit listing of 24 CWEs mapped to this category signals OWASP’s acknowledgement that many security vulnerabilities arise not from normal code-paths but exception/unexpected-path code.
- This emphasises the need for robust error-handling, clear fail-secure behaviour, sanity checks even in “rare” conditions.
Methodology & strategic approach
OWASP’s explains that the 2025 Top 10 remains data-informed, not purely data-driven. Their reasoning: test-data tells you what we can measure now; practitioner insight (via community survey) tells you what we should watch for.
Key points include:
- They asked for number of applications tested, number of applications with at least one instance of a given CWE. Frequency (number of instances) was deliberately not part of the ranking, because frequency can distort priority (tools may find thousands of low-impact instances, but risk is better modelled by “at least one” per application).
- The number of CWEs considered has ballooned: from ~30 in 2017 → ~400 in 2021 → 589 CWEs in this edition. This necessitated changes to category-structure.
- They cap the number of CWEs per category (max ~40) to keep categories manageable, training-friendly.
- Two of the ten categories are chosen based on community survey (to capture emerging risks not yet well-measured in data).
- Exploitability and technical impact remain part of the risk-equation: CVE data (CVSS exploit/impact) was used to help weight ranking, but the caveats of CVSS versions (v2→v3→v4) and mapping to CWEs are discussed in detail in the source.
Broader context & commentary
It’s helpful to step back and connect these category changes with broader software-security trends. Some additional observations:
Supply-chain and configuration risk rising: The move of “Software Supply Chain Failures” high in the list (and “Security Misconfiguration” leap-frogging) reflects the reality that modern systems depend heavily on third-party libraries, cloud infrastructure, container images, IaC (Infrastructure as Code), continuous build/deploy pipelines, feature-flags etc. Many attacks (e.g., dependency poisoning, mis-configured cloud buckets, mis-wired IAM policies) exploit exactly these modern vectors.
Root-cause focus intensifies: The shift from “Sensitive Data Exposure” (symptom) to “Cryptographic Failures” (cause) in earlier editions, and the continued emphasis in 2025, shows that OWASP wants practitioners to go deeper: “why did data leak?” rather than just “it leaked”. Similarly, “Mishandling of Exceptional Conditions” goes beyond the symptom of malfunction to the root-cause of logic/failure-path design.
Design-time vs run-time: The introduction (and retention) of “Insecure Design” means secure architecture/threat modelling remains a top-10 concern even as runtime/execution environment issues (config/supply chain) rise. This suggests a dual challenge: building right, and operating safely.
Tool-coverage gaps: OWASP repeatedly acknowledges that some categories are under-represented in test-data (supply chain, logging/alerting), which is why community survey input is explicitly used. This signals to organisations: don’t ignore those categories just because your tool-reports show low counts. They may simply be under-null-tested.
Training & awareness implications: The fact that there are ~248 CWEs across the ten categories (per the source you provided) means security programmes need to prioritise training and policies. It’s not realistic to tackle all ~600 CWEs at once; focusing on the top-10 categories as umbrella groups makes sense.
Evolving landscape means update rhythm matters: Some predictive commentary (see ZeroPath and other blogs) had already flagged supply chain and API/AI risks rising for 2025. Organisations that wait for formal release may already be behind the curve.
What this means for organisations & practitioners
Given the above changes, here are practical take-aways:
- Prioritise access control and configuration hygiene. Given their top two positions, organisations should ensure robust role/permission models, server-side enforcement of access, and strongly validate configurations across environments (dev/prod, cloud/IaC).
- Treat software supply-chain risk as strategic: include dependency inventory, CI/CD pipeline integrity, third-party component validation, build-artifact signing/verifications, monitoring of upstream library welfare/backdoor issues.
- Don’t deprioritise cryptographic controls and injection prevention — they are still very high risk (#4 and #5). Ensuring the right algorithms, key-management, safe APIs, parameterised queries still matters deeply.
- Focus on exceptional-path logic: Make sure your error-handling, fail-open cases, resource exhaustion, boundary conditions are tested as aggressively as “normal usage”. The new category underscores this.
- Elevate logging & alerting to first-class citizen in detection/response strategy: Logging alone is not sufficient — you need actionable alerting and response loops.
- Embed secure design/threat modelling early: The Insecure Design category may have slipped relative to others, but it remains vital for avoiding systemic architecture weaknesses.
- Recognise the limits of tooling/data: Because some categories are under-represented in automated test sets, rely also on expert review and community insight. Just because you don’t find many supply-chain issues in your scans doesn’t mean they aren’t real.
- Use the Top 10 as guidance not checklist: As some commentary notes, the OWASP Top 10 should be a starting point — it doesn’t cover everything.
Conclusion
The 2025 edition of the OWASP Top 10 demonstrates a maturing in application-security thinking: while perennial risks like access control and injection remain, the emergence of supply-chain vulnerabilities, misconfigurations, exceptional condition logic and “design-time” weaknesses underscores that the defence landscape is shifting. Organisations must adapt accordingly — investing not only in code scanning but in build-pipeline controls, configuration management, design-phase security and runtime logging/alerting.
