OWASP Top 10 2026: Latest Version & Full List

Written by the Rafter Team
· Updated

The OWASP Top 10 is the industry-standard list of the ten most critical web application security risks, published by OWASP, the Open Worldwide Application Security Project (formerly the Open Web Application Security Project), a nonprofit that maintains the list using contributed application vulnerability data, CVE and CWE data, and community survey input. First published in 2003, it is revised periodically to reflect contributed vulnerability data, CVE trends, and practitioner input.
If you are searching for the "OWASP Top 10 2026," here is the honest answer: the current and latest official edition is the OWASP Top 10:2025, the eighth installment, released in late 2025. There is no separate "2026 edition" — as of June 2026, the current official version is the OWASP Top 10:2025, and it is the version every category page on this blog now follows. The previous edition was published in 2021, so the 2025 release reflects data collected from 2021 to 2024, CVE and CWE analysis, and community survey input.
This guide walks through all ten 2025 categories in plain language, shows what changed since 2021, and answers the common questions about the latest version. Each entry links to a deeper page where you can read the fixes in detail.
Why the OWASP Top 10 Matters
The OWASP Top 10 is a baseline standard, not a niche reference. PCI DSS and many audit and security programs reference or map to the OWASP Top 10, and SOC 2 and ISO 27001 programs often use it as supporting application-security guidance, which is why so many enterprise security teams treat it as a baseline.
It is also a teaching tool. The list maps to common weakness categories that often contribute to real-world incidents, so reading it gives developers a working model of attacker behavior rather than an abstract checklist. Many common web application compromises involve weaknesses covered by one or more of these ten categories, which is why the list has become the common vocabulary for talking about application risk.
The OWASP Top 10 (2025 Edition — Current List)
This is the official 2025 ranking, in order. It matches the per-category guides linked under each entry.
A01 — Broken Access Control
Broken access control happens when users can reach data or perform actions outside their intended permissions. It holds the #1 position from 2021, and in 2025 it absorbed Server-Side Request Forgery (SSRF), which is now treated as an access-control failure.
A common example is changing user_id=123 to user_id=124 in a request and seeing another customer's account, an "insecure direct object reference." The fix is to enforce authorization on the server for every request, apply least privilege, and add automated tests that prove permission checks hold.
Read more: A01 Broken Access Control
A02 — Security Misconfiguration
Security misconfiguration covers insecure defaults, unnecessary open services, missing hardening, and overly verbose error pages. It is the biggest mover of the 2025 edition, climbing from #5 in 2021 to #2; OWASP notes that misconfigurations were more prevalent in this cycle's contributed data.
A classic case is an Amazon S3 bucket left publicly readable, exposing data to anyone who finds the URL. The fix is to harden configurations by default, remove unused features and accounts, and scan infrastructure-as-code for risky settings before they ship.
Read more: A02 Security Misconfiguration
A03 — Software Supply Chain Failures
Software Supply Chain Failures is a new and broadened category for 2025. It expands the old "Vulnerable and Outdated Components" entry to cover the whole dependency ecosystem, including compromised packages, malicious updates, and weaknesses in build and distribution pipelines.
The Log4Shell vulnerability, which let attackers run code worldwide through a single logging library, is the kind of risk this category captures. The fix is to inventory dependencies with a Software Bill of Materials, run continuous dependency scans, and verify the integrity of what you pull into a build.
Read more: A03 Software Supply Chain Failures
A04 — Cryptographic Failures
Cryptographic failures expose sensitive data through weak, missing, or misused cryptography. It dropped from #2 in 2021 to #4 in 2025, though the impact remains severe.
Storing passwords in plain text, or hashing them with a broken algorithm like MD5, is a textbook example that turns one database leak into mass credential theft. The fix is to use TLS in transit, hash passwords with a strong function such as bcrypt, scrypt, or Argon2, and encrypt sensitive data at rest.
Read more: A04 Cryptographic Failures
A05 — Injection
Injection occurs when untrusted input is interpreted as a command or query, letting an attacker change what the application executes. It moved from #3 in 2021 to #5 in 2025, and it still includes cross-site scripting.
A SQL query built by concatenating user input — so that 1 OR 1=1 returns every row instead of one — is the canonical example. The fix is to use parameterized queries or a well-maintained ORM, validate input against an allowlist, and run the database with least privilege.
A06 — Insecure Design
Insecure design refers to security flaws baked into the architecture itself, not bugs in otherwise sound code. It moved from #4 in 2021 to #6 in 2025, and no amount of clean implementation fixes a fundamentally unsafe design.
A banking flow with no rate limiting or step-up authentication on transfers is an example: the code may be correct, but the design invites abuse and fraud. The fix is to threat-model during design, write security requirements alongside functional ones, and reach for proven secure design patterns.
Read more: A06 Insecure Design
A07 — Authentication Failures
Authentication Failures, renamed in 2025 from "Identification and Authentication Failures," covers weak or broken login, session, and identity flows. It allows attackers to impersonate users or hijack sessions.
A session token that never expires, or a login endpoint with no protection against credential stuffing, is a representative example. The fix is to use OIDC for authentication and appropriate OAuth 2.0 flows for delegated authorization, require multi-factor authentication, and manage sessions securely with proper expiry and rotation.
Read more: A07 Authentication Failures
A08 — Software or Data Integrity Failures
Software or data integrity failures arise when an application trusts code, data, or updates without verifying them. This is where many supply-chain-style attacks land once malicious content is already trusted.
An auto-update mechanism that installs packages without verifying a signature is a concrete example, as is a CI/CD pipeline that runs unverified scripts. The fix is to use signed artifacts, verify checksums and signatures, and protect the integrity of the build and deployment pipeline.
Read more: A08 Software or Data Integrity Failures
A09 — Security Logging and Alerting Failures
Security Logging and Alerting Failures, renamed in 2025 to emphasize alerting, covers missing or insufficient logging, detection, and response for security-relevant events. Without effective logging and alerting, attacks may go undetected or take longer to investigate.
If an attacker brute-forces accounts and nothing logs or alerts on the spike in failed logins, that is this category in action. The fix is to centralize logging, capture authentication events, access-control failures, and server-side errors, and wire those signals to alerts a human or system will actually see.
Read more: A09 Security Logging and Alerting Failures
A10 — Mishandling of Exceptional Conditions
Mishandling of Exceptional Conditions is the second new category in 2025. It covers improper error handling, logic that fails open instead of closed, and unexpected states that leave the application in an insecure condition.
An example is an authorization check that throws an exception and, instead of denying access, lets the request through. The fix is to fail closed by default, handle errors deliberately rather than swallowing them, and avoid leaking internal detail in error responses.
Read more: A10 Mishandling of Exceptional Conditions
What Changed in the Latest OWASP Top 10 (vs 2021)
The 2025 edition is a meaningful reshuffle, not a cosmetic refresh. Here is what moved between 2021 and 2025.
Two new categories. Software Supply Chain Failures (A03) is new and broadens the former "Vulnerable and Outdated Components" to cover the entire dependency and build ecosystem. Mishandling of Exceptional Conditions (A10) is also new, covering improper error handling, logic errors, and failing open.
SSRF folded into Broken Access Control. Server-Side Request Forgery was its own category in 2021. In 2025 it is treated as a form of broken access control under A01, which keeps the top spot.
Two renames. "Identification and Authentication Failures" became simply "Authentication Failures" (A07), and "Security Logging and Monitoring Failures" became "Security Logging and Alerting Failures" (A09) to stress that detection has to trigger a response, not just a log line.
The big climb. Security Misconfiguration jumped from #5 to #2, the largest move on the list; OWASP notes that misconfigurations were more prevalent in this cycle's contributed data.
What slid down. Cryptographic Failures fell from #2 to #4, Injection from #3 to #5, and Insecure Design from #4 to #6 — not because they became less dangerous, but because the data reranked the list around them.
How to Apply This as a Developer
Start where the data points: broken access control and security misconfiguration are the two highest-ranked risks, so audit authorization logic and your default configurations first. Both are common in fast-moving codebases and in AI-generated code, where missing checks and unsafe defaults slip through easily.
Then make the checks continuous instead of occasional. Shifting security left — running scans on every push rather than once before release — keeps these categories from accumulating. Rafter scans code and dependencies on each pull request and maps findings to OWASP categories so issues surface while they are still cheap to fix.
Frequently Asked Questions
What is the OWASP Top 10 2026 / latest version?
There is no separate 2026 edition. As of June 2026, the current official version is the OWASP Top 10:2025. It ranks the ten most critical web application security risks, led by Broken Access Control and Security Misconfiguration.
When was it released, and how often is it updated?
The 2025 edition is the eighth installment and was released in late 2025, replacing the 2021 edition. OWASP revises the list roughly every three to four years as new contributed vulnerability data, CVE trends, and survey input accumulate.
Is there an official "OWASP Top 10 2026" edition?
No. "OWASP Top 10 2026" is a common way people search for the current list, but OWASP labels editions by release year, and the most recent is 2025. The next edition will carry whatever year it is published in, not 2026.
What's the difference between the OWASP Top 10 and the OWASP API Security Top 10?
The OWASP Top 10 covers web application risks broadly, while the OWASP API Security Top 10 is a separate list focused specifically on API-layer risks such as Broken Object Level Authorization and Broken Object Property Level Authorization. They are maintained as distinct projects and updated on their own schedules, so API-heavy teams generally use both.
Conclusion
The OWASP Top 10 is a catalog of the weakness categories that often contribute to real-world incidents, and the current 2025 edition emphasizes access control, misconfiguration, and software supply chain risk. Treating it as your security baseline, and not your ceiling, is the practical takeaway.
The fastest way to act on it is to audit your highest-ranked risks first, then automate scanning so new code is checked against these categories continuously rather than reviewed once before release.