What the ten risk categories mean in plain terms, what changed in the 2025 edition, and how to use the list without turning it into a checkbox exercise.
In short
The OWASP Top 10 is a ranked list of the ten most critical security risk categories for web applications, published by the OWASP Foundation. The 2025 edition puts broken access control first, adds software supply chain failures and mishandling of exceptional conditions, and merges SSRF into access control. Use it as an awareness baseline, not a complete standard.
The list is the most widely cited reference in application security (applikationssäkerhet). Customers ask about it in security questionnaires, tenders mention it, and many scanners report against it. This explainer is written by Devies, a Gothenburg-based product and engineering consultancy, for product owners, engineering managers and CTOs who need to understand what each category means for their product and what to ask their teams.
What is the OWASP Top 10?
The OWASP Top 10 is an awareness document that ranks the most important categories of web application security risk, based on contributed vulnerability data and a community survey.
OWASP, the Open Worldwide Application Security Project, is a non-profit foundation that produces free, open security resources. The OWASP Top 10:2025 is the eighth edition since the first list in 2003. According to the 2025 introduction, contributors supplied data on more than 2.8 million applications, and the ten categories group 248 CWEs, the standard identifiers for types of software weakness. Two categories were chosen from a community survey rather than the data, to capture risks that testing data does not yet show well.
Often confused with
What it is
How it differs from the Top 10
OWASP ASVS
What it is
The Application Security Verification Standard, with detailed, testable requirements at three levels
How it differs from the Top 10
ASVS is a verification standard; the Top 10 is an awareness list
CWE Top 25
What it is
MITRE's list of the most dangerous individual software weaknesses
How it differs from the Top 10
CWEs are specific weaknesses; Top 10 categories group many of them
A penetration test
What it is
A time-boxed attack on your system by testers
How it differs from the Top 10
A pentest may use the Top 10 as a lens, but tests your specific system
Compliance
What it is
Meeting a legal or contractual requirement
How it differs from the Top 10
No law requires the Top 10 itself, though buyers often reference it
What are the ten risks in the 2025 edition?
The 2025 list keeps broken access control at number one, moves security misconfiguration up to second place and adds two new categories.
- A01 Broken Access Control. Users can act outside their permissions, such as viewing another customer's order by changing an ID in the URL. Server-side request forgery (SSRF) is now included here. Ask: is every request authorised on the server, and do tests check it?
- A02 Security Misconfiguration. Default settings, open cloud storage, verbose errors or unnecessary features. Ask: are environments built from reviewed configuration as code?
- A03 Software Supply Chain Failures. Vulnerable, malicious or unmaintained dependencies, build tools and pipelines. It broadens the 2021 category on vulnerable and outdated components. Ask: do we have an SBOM and alerts for new vulnerabilities? Our guide to software supply chain security goes deeper.
- A04 Cryptographic Failures. Sensitive data sent or stored without proper encryption, weak algorithms or poorly managed keys. Ask: where is personal and payment data, and how is it protected in transit and at rest?
- A05 Injection. Untrusted input interpreted as code or commands, such as SQL injection and cross-site scripting. Ask: do we use parameterised queries and output encoding by default?
- A06 Insecure Design. Flaws in the design itself, such as a password reset flow that can be abused, which no amount of correct code can fix. Ask: do we threat-model new features?
- A07 Authentication Failures. Weak login, session handling or credential recovery. Ask: do we support MFA, rate-limit login and use a proven identity provider?
- A08 Software or Data Integrity Failures. Code, updates or data accepted without verifying integrity, for example unsigned updates or insecure deserialisation. Ask: are builds and updates signed and verified?
- A09 Security Logging and Alerting Failures. Attacks go unnoticed because events are not logged, monitored or acted on. Ask: would we know within a day if an account were taken over?
- A10 Mishandling of Exceptional Conditions. New in 2025: errors, edge cases and unexpected states that leave the application failing open, leaking information or behaving unpredictably. Ask: what happens when a dependency times out mid-transaction?
What changed from the 2021 edition?
The 2025 edition reorders the list, adds two categories, merges one and renames two, reflecting how modern applications are built and attacked.
- Rank changes: Security Misconfiguration rose from fifth to second. Cryptographic Failures fell from second to fourth, Injection from third to fifth and Insecure Design from fourth to sixth.
- New: Software Supply Chain Failures, which expands the 2021 category on vulnerable and outdated components, and Mishandling of Exceptional Conditions.
- Merged: SSRF, a separate category in 2021, is now part of Broken Access Control.
- Renamed: Identification and Authentication Failures became Authentication Failures, and Security Logging and Monitoring Failures became Security Logging and Alerting Failures, stressing that logs are only useful if someone acts on them.
For leaders, the clearest signal is the rise of supply chain risk and misconfiguration. Much of today's attack surface sits in dependencies, pipelines and cloud settings rather than in code your team writes.
How should product teams use the OWASP Top 10?
Use the list to build shared awareness and to check that your development process covers each risk category, then use a detailed standard for verification.
The list is short enough to train every developer, product owner and tester on, which is its main value. It is not a checklist that proves a product is secure: each category covers many weaknesses, and the list deliberately leaves out risks that matter in specific contexts. Four practical uses:
- Map controls to categories. For each risk, name the practice that addresses it: code review, automated tests, threat modelling, dependency scanning or monitoring. Our article on DevSecOps and security in every release shows how these fit into a pipeline.
- Choose testing tools. Static analysis, dynamic testing and dependency analysis each cover different categories. Our comparison of SAST, DAST and SCA explains which finds what.
- Answer customer questionnaires with concrete practices per category instead of "we follow OWASP".
- Graduate to ASVS when you need testable requirements for a security-critical product or a contract.
Devies saw the value of this kind of everyday integration in its work with Zenseact on safety-critical automotive software, where security requirements were turned into development tasks, threat modelling was part of normal work and dependency tracking with an SBOM ran inside the CI/CD pipeline.
Keep reading
From our work
Consilium and Devies Cybersecurity+Consilium Safety Group and Devies Cybersecurity+: a partnership for future-proof cybersecurity in fire, flame and gas safety systems.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the current version of the OWASP Top 10?
As of October 2026, the current version is the OWASP Top 10:2025, the eighth edition of the list. It replaced the 2021 edition and introduced two new categories, Software Supply Chain Failures and Mishandling of Exceptional Conditions, while merging server-side request forgery into Broken Access Control. OWASP typically updates the list every three to four years, based on contributed data and a community survey.
Is following the OWASP Top 10 enough to secure an application?
No. The OWASP Top 10 is an awareness document covering the most common and critical risk categories, not a complete security standard. It does not include every weakness relevant to your product, and it does not define testable requirements. Use it to train teams and check process coverage, then use the OWASP ASVS, threat modelling and testing to verify the security of a specific application.
Does the OWASP Top 10 apply to mobile apps and APIs?
The Top 10 is written for web applications, and much of it applies to the APIs behind mobile apps as well. OWASP also publishes separate lists for specific contexts, including the API Security Top 10 and the Mobile Top 10, which address risks such as object-level authorisation in APIs and insecure data storage on devices. Use the list that matches what you build.
Is the OWASP Top 10 a legal requirement?
No law requires compliance with the OWASP Top 10 itself. Laws such as the Cyber Resilience Act and the Swedish Cybersecurity Act require appropriate, risk-based security measures, and customers and tenders often reference the Top 10 as evidence of good practice. Treat it as a common language for showing how you handle well-known risks, not as a certificate of compliance.
