Application security stops being a developer topic at the point where a breach becomes a board topic. This guide walks the current edition of the best-known risk list category by category, explains how it is compiled, and shows how to use it to decide what gets fixed first.
Quick Overview
What you’ll learn:
- Which edition of the list is current and why the edition matters
- How the list is compiled, and why it is data-informed rather than data-driven
- What each risk category covers, in language a non-specialist can act on
- What changed between the previous edition and the current one
- Why the list is a prioritisation instrument and not a compliance checklist
- Where the list ends and a real application security programme begins
Who this article is for:
- Technology leaders who approve security work and its trade-offs
- Product owners deciding what a release must satisfy before it ships
- Engineers who need to explain a risk to someone who controls the budget
Reading time: 16 minutes
The Edition This Article Describes
Naming the edition is not pedantry. Categories are renamed, merged and reordered between releases, and an article that discusses “the top ten” without saying which one leaves the reader unable to check anything it claims. This article describes the OWASP Top 10:2025 edition, published by the OWASP Foundation, which the project identifies as the eighth installment of the list and as the current released version.
The distinction has practical weight because the previous edition remains in wide circulation. Contracts, internal standards, supplier questionnaires and training material written between the editions refer to a category set that no longer matches the published one. An organisation that mandates compliance with a specific edition in a contract has created a dated obligation, and an organisation that mandates “the OWASP Top 10” without qualification has created an obligation that changes underneath it.
The workable approach is to reference the list by edition wherever the reference is contractual or auditable, and to review those references when a new edition lands. That review is small work if it is scheduled and awkward work if it is discovered during a supplier audit.
Why This Belongs on a Management Agenda
For years application security was filed as a technical problem belonging to whoever wrote the code. That filing is now wrong in a way that costs money. A web application is, for most organisations, the surface through which customers are served, orders are taken and records are held — which makes an attack on it an attack on the operating business rather than on a system.
The consequences that follow a serious application compromise are distributed across functions that do not report to engineering. Service interruption belongs to operations. Notification obligations and regulatory correspondence belong to legal and compliance. Customer communication belongs to marketing and support. Contractual exposure belongs to whoever signed the service commitments. Engineering owns the repair and none of the rest, which is precisely why the decisions that determine the exposure cannot sit with engineering alone.
The practical implication is about sequencing rather than sentiment. Security work competes with feature work for the same finite capacity, and that competition is resolved by whoever sets priorities. When a technology leader declines to look at the trade-off, it does not disappear; it is resolved implicitly, in favour of whatever has a delivery date attached. A risk list is useful to that leader for a narrow and important reason: it converts a vague obligation to be secure into a small set of named categories that can be asked about, budgeted for and tracked over time.
The questions worth asking are correspondingly plain. Which of these categories apply to our systems? Which have we tested for, and when? Which recur across teams? What would we do differently if the answer were embarrassing?
What the List Is, and How It Is Built
The OWASP Top 10 is a standard awareness document, not a technical standard and not a certification scheme. It represents a broad consensus about the most critical security risks to web applications, and its stated purpose is to be a first step towards changing how software is built rather than an exhaustive specification of what secure software must do. Reading it as a compliance target produces applications that satisfy ten categories and fail on the eleventh problem.
The compilation method is worth understanding, because it explains the list’s strengths and its blind spots. The OWASP Top 10:2025 methodology describes the process as data-informed but not blindly data-driven: categories are ranked using contributed testing data, and a small number of positions are promoted or highlighted based on a community survey of practitioners. The reason given is that testing data necessarily looks backwards. It takes considerable time for a newly understood weakness to become reliably testable at scale, and some genuinely important risks may never be testable at scale at all. The survey exists to counterweight that lag.
The data model changed for this edition as well. The OWASP Top 10:2025 methodology asked contributors for the number of applications tested and the number with at least one instance of a given weakness, which yields prevalence within the application population rather than raw counts. Whether an application contains a handful of instances of a weakness or thousands is deliberately excluded from the calculation, because instance counts measure the diligence of the tester as much as the state of the software.
A pair of consequences follow for anyone using the list to make decisions. First, position on the list reflects a blend of measured prevalence, exploitability, impact and practitioner judgement, not a single measured quantity, so treating rank as a precise ordering of your own risk is a misreading. Second, categories that are hard to test are systematically underrepresented in the data, which is exactly why the survey mechanism exists — and why an absence of findings in a category is weak evidence of an absence of risk.
What Changed From the Previous Edition
The OWASP Top 10:2025 edition introduces two new categories and one consolidation relative to the 2021 edition, with an explicit editorial preference for naming root causes rather than symptoms.
The consolidation is the most consequential for anyone maintaining a mapping. Server-Side Request Forgery, which held its own position in the previous edition, has been rolled into Broken Access Control. Organisations whose internal standards enumerate the previous categories one by one will find that a category they track has disappeared as a heading while the underlying risk has not disappeared at all.
The first new category, Software Supply Chain Failures, is an expansion of the previous edition’s Vulnerable and Outdated Components. The broadening is deliberate: it covers compromises occurring anywhere across the ecosystem of dependencies, build systems and distribution infrastructure, not only the narrower case of a dependency with a published vulnerability. The OWASP Top 10:2025 methodology records that this category was overwhelmingly voted a top concern in the community survey, that it has a limited presence in the collected data, and that the project attributes the gap to the difficulty of testing for it rather than to its absence in the wild. It also carries the highest average exploit and impact scores from associated vulnerability records.
The second new category, Mishandling of Exceptional Conditions, gathers improper error handling, logical errors and systems that fail open. The OWASP Top 10 documentation notes that some of these weaknesses were previously filed under general code quality, which the project judged too broad to be actionable. Naming them separately is a bet that a specific category produces better guidance than a general one.
The OWASP Top 10:2025 edition also renamed two categories for precision. Identification and Authentication Failures became Authentication Failures, and Security Logging and Monitoring Failures became Security Logging and Alerting Failures — the latter change carrying an argument rather than a preference, since logging without alerting produces evidence nobody acts on.
Access, Configuration and Supply Chain
A01 Broken Access Control
Access control failures occur when a user can perform an action or reach data outside their permissions. The category retains the top position in the OWASP Top 10:2025 edition; contributed data indicates that on average 3.73% of applications tested contained at least one of the forty weaknesses mapped to it.
The reason it stays at the top is structural rather than accidental. Authorisation is the one control that cannot be delegated to a framework default, because only the application knows which user may see which record. Every endpoint is an independent opportunity to get it wrong, and the failure is invisible in normal use — the application behaves correctly for users who do not try. For a leader, the useful question is not whether access control exists but whether it is enforced centrally and denied by default, because a codebase where each endpoint implements its own check will eventually contain one that does not.
A02 Security Misconfiguration
Misconfiguration moved from fifth position in the previous edition to second, and the OWASP Top 10:2025 methodology attributes the rise to prevalence in the current data: 3.00% of tested applications contained at least one of the sixteen weaknesses in the category. The explanation offered is that software engineering keeps moving application behaviour out of code and into configuration.
That shift is the point worth carrying into a management conversation. Default credentials, verbose error pages, permissive storage permissions, unnecessary features left enabled and stale cloud rules are not coding errors and will not be found by reviewing code. They are found by testing the deployed system in each environment, and they reappear whenever an environment is rebuilt by hand.
A03 Software Supply Chain Failures
The category covers breakdowns in how software is built, distributed and updated — compromised or vulnerable third-party code, build tooling, package repositories and update channels, including transitive dependencies that nobody chose deliberately.
For decision-makers this is the category with the widest gap between attention and control. Answering it requires knowing what is actually in a build, which is a tooling and process question rather than a review question: dependency inventory, provenance of build artefacts, control over the pipeline that produces them, and a route to patch quickly when a dependency is found to be compromised. The OWASP Top 10 documentation is explicit that the limited data presence reflects testing difficulty rather than safety.
Cryptography, Injection and Design
A04 Cryptographic Failures
The category covers data that should have been protected and was not: absent encryption in transit or at rest, weak or obsolete algorithms, poor key management, and password storage that does not resist offline attack. In the OWASP Top 10:2025 edition it sits at fourth position, down from second, with an average of 3.80% of tested applications containing at least one of its thirty-two mapped weaknesses; the project notes that failures here typically lead to sensitive data exposure or system compromise.
The practical guidance is unglamorous and effective: use vetted implementations rather than writing primitives, classify what genuinely needs protection, and treat key management as an operational process with owners and rotation rather than as a configuration value set once.
A05 Injection
Injection covers untrusted input interpreted as a command — database queries, operating system calls, template engines and, in its cross-site scripting form, the browser. It ranks fifth in the OWASP Top 10:2025 edition and is among the most heavily tested categories, with the largest number of associated vulnerability records across its thirty-eight mapped weaknesses. The category spans a wide impact range, from high-frequency, low-impact scripting flaws to low-frequency, high-impact database injection.
Its persistence after decades of attention is a lesson in itself: the defences are well understood, and they fail wherever a shortcut is convenient. Parameterised queries, contextual output encoding and validation against an allow-list are the answer, and the management question is whether the codebase makes the safe path the easy one.
A06 Insecure Design
Insecure design covers applications that are built correctly to a flawed specification — a password reset flow that can be abused, a business process that trusts a value the client controls, a workflow with no rate limiting where abuse is free. No amount of careful implementation fixes a design that was wrong.
The category slipped from fourth to sixth position in the OWASP Top 10:2025 edition, and the project attributes the movement to genuine industry improvement in threat modelling and design-stage attention rather than to a decline in importance. This is the category that most directly requires leadership action, because it is addressed by adding a step to the process where features are specified — and only someone who controls that process can add it.
Authentication, Integrity, Alerting and Exceptions
A07 Authentication Failures
Renamed from Identification and Authentication Failures, this category covers weaknesses in how identity is established and sessions are maintained: credential stuffing without defences, weak recovery flows, session tokens that do not expire or rotate. It holds seventh position in the OWASP Top 10:2025 edition across thirty-six mapped weaknesses, and the project observes that wider adoption of standardised authentication frameworks appears to be reducing occurrences.
That observation contains the recommendation. Authentication is a solved problem for most organisations, and the solution is to adopt a maintained identity platform rather than to implement login logic in each application.
A08 Software or Data Integrity Failures
This category concerns failures to maintain trust boundaries and to verify the integrity of software, code and data artefacts. It sits at a lower level than the supply chain category: whether an update is verified before it is applied, whether serialised data from an untrusted source is deserialised without checks, whether a build artefact is the one that was reviewed.
The organisational question is whether anything in the delivery path verifies what it receives, or whether trust is inherited by default from the fact that an artefact arrived through the usual channel.
A09 Security Logging and Alerting Failures
The rename in the OWASP Top 10:2025 edition carries the argument: excellent logging with no alerting is of minimal value for identifying incidents. The category covers events that are not logged, logs that cannot be searched, and detections that fire into a void.
The project notes that this category will always be underrepresented in testing data and was again voted into the list by survey participants — a useful illustration of why the survey mechanism exists. The management test is concrete: pick a plausible malicious action, and ask how long it would take to notice it and who would receive the signal. If the answer requires a person to go looking, the control does not exist. Organisations formalising this capability will find the discipline described in our guide to threat hunting.
A10 Mishandling of Exceptional Conditions
New in this edition, the category collects improper error handling, logical errors and systems that fail open, gathering weaknesses across error messages that disclose sensitive information, unhandled missing parameters, improper handling of insufficient privileges and null dereferences.
The unifying idea is that an application which is unsure what to do next has mishandled an exceptional condition, and the security-relevant question is what it does in that state. Failing closed is a design decision, and it is one that has to be made before the situation occurs.
Using the List as a Management Instrument
The most common misuse of this list is as a checklist appended to a security review. Boxes get ticked, the application ships, and the exercise has measured paperwork rather than risk.
Used well, the list does three things a checklist cannot. It supplies a shared vocabulary in which a developer, a security specialist and an executive can discuss the same risk without translation loss. It provides a defensible prioritisation frame: categories that are prevalent, easy to exploit and damaging deserve attention before categories that are none of those, and the published ranking is a reasonable starting hypothesis when local evidence is absent. And it exposes systemic weakness — if the same category recurs across unrelated applications, the defect is in the platform, the training or the process, not in the teams.
Depth comes from the project’s other outputs. The OWASP Application Security Verification Standard converts the awareness-level categories into verifiable requirements at graded levels of rigour, which is what a contract or an internal standard actually needs to reference. The OWASP Web Security Testing Guide describes how to test for the weaknesses, which is what a testing programme needs. Organisations that adopt the awareness list and stop there have taken the map and left the terrain. Teams building the underlying understanding first will find our overview of web application security a useful foundation, and those commissioning assessments should read our guide to where to start with penetration testing.
One extension is worth planning for now. Applications built around large language models introduce failure modes — prompt injection, insecure output handling, training data and model supply chain risks — that the web application list does not cover, and OWASP maintains separate material for them. Organisations shipping such features should treat that material as a parallel obligation rather than an optional appendix; AI and ML model security training covers the adversarial techniques and the specific list that applies there.
From List to Programme
Turning a risk list into reduced risk is a programme question, and the sequence that works is unremarkable.
Start with an inventory. Most organisations cannot enumerate their internet-facing applications with confidence, and an application nobody owns will not be patched. Then establish visibility: dependency inventory, automated scanning wired into the build, and periodic assessment by people who did not write the code. Then fix the systemic causes rather than the findings — a centralised authorisation component, hardened deployment templates, a maintained identity platform and a build pipeline that verifies what it consumes remove whole categories rather than individual defects.
The shift-left principle belongs here, and it is frequently misapplied. Moving security activity earlier reduces cost only if the earlier activity is genuinely capable of catching the defect. Adding a scanner to a pull request catches a narrow class of issues cheaply; it does nothing about a flawed design, which is caught by a design review and by nothing else. Shifting left without shifting capability transfers work to developers and calls the transfer a strategy.
Finally, measure something that survives scrutiny. Counting resolved findings measures scanner output. Time from disclosure to patched in production, coverage of the application inventory by any assessment at all, and the recurrence rate of a category across teams tell you whether the programme is working. Those numbers are harder to produce and considerably harder to argue with.
Build Your Skills
Teams that need to move from reading the list to running the controls behind it — testing in the pipeline, triaging findings, and building the practices that remove categories rather than defects — will find that ground covered in application security, DevSecOps and OWASP testing training.
Frequently Asked Questions (FAQ)
Is satisfying the list enough to call an application secure?
No, and the project does not claim otherwise. The document is an awareness list describing broadly critical risks, deliberately short enough to be remembered. Applications have context-specific risks that no general list contains, and a verification standard rather than an awareness list is the right instrument when a definitive statement about an application is required.
Which edition should a contract or internal standard reference?
Reference an edition explicitly and review the reference when a new one is published. An unqualified reference creates an obligation whose content changes without either party agreeing to the change, and a reference to a superseded edition quietly ages into a requirement that no longer matches published material. Both failure modes are avoidable with a scheduled review.
Does the ranking reflect the risk in our own applications?
Only as a starting hypothesis. The ranking blends contributed testing data with practitioner judgement across a broad population, and your architecture, exposure and threat profile are not that population. Use the ranking when you have no local evidence, and replace it with your own findings as soon as you have them.
Why is a category we never find in scans still ranked highly?
Because testability and importance are different properties. The project states plainly that some categories are underrepresented in data because they are hard to test at scale, and uses a practitioner survey specifically to counterweight that gap. An empty scan result in such a category is evidence about your tooling, not about your exposure.
Where should an organisation with nothing in place start?
With an accurate inventory of internet-facing applications and their owners, then with authorisation and configuration — the categories at the top of the list are there because they are both prevalent and consequential. Systemic fixes outrank individual findings: a shared authorisation component and hardened deployment templates prevent recurrence in a way that closing tickets does not.