OWASP Top 10 2025: All 10 Risks Explained With Examples

The OWASP Top 10 2025 is the current edition of OWASP's awareness list of the most critical web application security risks. In order, the ten categories are A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions. Compared with the 2021 list, two categories are new, SSRF was merged into Broken Access Control, and Security Misconfiguration jumped from fifth to second.

The OWASP Top 10 2025 List at a Glance

Later sections cover each category in the same way: a short definition, a dated real-world CVE or incident, how a penetration tester checks for it in an authorized engagement, and the controls that prevent it.

OWASP's own pages write A09 as "Security Logging & Alerting Failures"; the meaning is identical.

What Is the OWASP Top 10?

The OWASP Top 10 is a free awareness document published by the OWASP Foundation, a nonprofit that is not affiliated with any technology company. It represents a broad consensus about the most critical security risks to web applications and is meant to start conversations, training and testing programs, not to be a complete list of every possible weakness.

The list was first published in 2003, and the 2025 release is the eighth installment. OWASP's project page now lists 2025 as the current version, and the official repository on GitHub marks the 2025 edition as released and the 2021 edition as superseded. The release was planned for OWASP's Global AppSec USA conference in Washington, D.C., in November 2025.

Three facts about how the 2025 list was built matter when you read it:

• It is data-informed, not purely data-driven. OWASP ranked categories using vulnerability data contributed for more than 2.8 million applications, then chose eight of the ten from that data and two from a community survey of practitioners. The survey picks were Software Supply Chain Failures and Security Logging and Alerting Failures, both risks that automated testing struggles to measure.
• Each category is a group of weaknesses, not a single bug. OWASP analyzed 589 Common Weakness Enumerations (CWEs) and mapped 248 of them into the ten categories, capping any one category at 40. That is why "Injection" covers both cross-site scripting and SQL injection.
• Categories favor root causes over symptoms. OWASP grouped weaknesses by cause where it could, such as a cryptographic failure, rather than by effect, such as sensitive data exposure.

The OWASP introduction to the 2025 edition documents the full methodology, including how CVE exploit and impact scores were weighted.

OWASP Top 10 2021 vs 2025: What Changed

The 2025 edition has two new categories and one consolidation. Three categories were renamed, and four moved position.

What the changes mean in practice:

• SSRF did not disappear. It now sits inside A01 as CWE-918, next to CSRF and the classic access control weaknesses. If your reports or tooling still tag findings as "A10:2021 SSRF," map them to A01:2025.
• Supply chain risk grew beyond outdated libraries. The old A06 category asked whether you ran components with known vulnerabilities. The new A03 also covers compromised maintainers, malicious packages, build systems and distribution infrastructure. OWASP says half of survey respondents ranked it the number one risk.
• Misconfiguration rose because more behavior lives in configuration. OWASP found some form of misconfiguration in every application tested and attributes the rise to software that is increasingly configured rather than coded.
• Insecure Design dropped, but OWASP credits progress, not lower risk. The authors report noticeable industry improvement in threat modeling and secure design since the category was introduced in 2021.
• Error handling became its own risk. A10:2025 collects 24 CWEs about improper error handling, logical errors and failing open, several of which OWASP previously treated as general code quality.

The 2021 list is still published as a reference, but new testing scopes, policies and training should use the 2025 categories.

How to Read Each Category

Real vulnerabilities rarely respect category boundaries. A single CVE can involve a missing authorization check (A01), an unrestricted file upload (A06) and a deserialization flaw (A08). The examples below are assigned to the category whose CWE mapping fits best, using the CWE published in the National Vulnerability Database (NVD) or the vendor's own description. The testing notes describe what a tester verifies in a scoped, authorized engagement; they are not instructions for testing systems you do not own.

The OWASP Top 10 2025 Categories Explained

A01:2025 Broken Access Control

Definition. Broken access control means the application lets a user act outside their intended permissions, such as reading another customer's records, calling an admin function or editing data they should only view. In 2025 the category also includes server-side request forgery, where the server is tricked into sending requests to destinations the attacker cannot reach directly.

Why it ranks first. OWASP found some form of broken access control in 100% of the applications tested, and on average 3.73% of applications had at least one of the category's 40 CWEs. It has the most occurrences of any category in the contributed data.

Real example. On March 2, 2021, Microsoft disclosed four Exchange Server zero-days exploited by the HAFNIUM group. The first link in the chain, CVE-2021-26855, was a server-side request forgery flaw that let an attacker send arbitrary HTTP requests and authenticate as the Exchange server. NVD maps it to CWE-918, which OWASP now places in A01.

How pentesters test for it. Testers build a role and object matrix before they touch a request: every role, every object type, and who should be able to read, create, change or delete it. Using two or more test accounts per role, they replay legitimate requests while changing only the identity, the object identifier or the HTTP method, then compare what the server returns. They also check whether controls hidden in the user interface are enforced on the server, whether unauthenticated users can reach admin routes, and whether tenant boundaries hold.

For SSRF, they list every feature that fetches a URL, such as webhooks, file importers, link previews and PDF renderers, and confirm in a controlled way whether the server can be made to reach internal or cloud metadata addresses.

How to prevent it.

• Deny by default and enforce every check in trusted server-side code, never only in the browser.
• Implement access control once, in a shared component, and reuse it everywhere.
• Check record ownership on every read and write, not just whether the user is logged in.
• Invalidate server-side sessions on logout and keep stateless tokens short-lived.
• For SSRF, allowlist the destinations a feature may call, block internal address ranges at the network layer, and use the hardened metadata service options your cloud provider offers.
• Log access control failures and alert on repeated attempts.

DeepStrike deep dives. Object-level authorization in APIs (BOLA) is covered in our guide to API penetration testing, and a real case of broken authorization on a destructive endpoint is walked through in our path traversal in DELETE requests case study. Our IDOR guide explains object-level access control flaws in depth. Our SSRF guide covers cloud metadata attacks and defenses.

A02:2025 Security Misconfiguration

Definition. Security misconfiguration happens when a system is deployed with insecure settings: default accounts left enabled, unnecessary features or sample apps installed, overly permissive cloud storage, verbose error pages, missing security headers or weak XML parser settings. The code may be sound, but the way it is configured exposes data or functionality to attackers.

Why it moved up. Misconfiguration climbed from fifth place in 2021 to second. OWASP found some form of it in every application tested, with an average incidence rate of 3.00% across its 16 CWEs, which include XML External Entity (XXE) processing.

Real example. On September 18, 2023, the Microsoft Security Response Center reported that an employee had published a storage URL in a public GitHub repository while sharing open-source AI models. The URL contained an overly permissive Shared Access Signature (SAS) token for an internal storage account. Researchers used it to reach workstation backups and internal Teams messages of two former employees. Microsoft said no customer data was exposed; it revoked the token two days after the June 22, 2023 report. Microsoft stressed there was no flaw in Azure Storage itself: the exposure came from how the token was scoped and shared.

How pentesters test for it. Testers compare what is deployed against what should be: response headers, TLS settings, enabled HTTP methods, directory listing, debug and admin endpoints, default content, and how errors are rendered. In cloud-backed applications they review storage, function and identity permissions within scope, and check whether client-side configuration exposes keys or overly broad backend rules. They also confirm that development settings, such as permissive CORS or verbose logging, did not reach production.

How to prevent it.

• Use a repeatable, automated hardening process so development, staging and production are configured the same way, with different credentials.
• Ship a minimal platform: remove unused features, frameworks, sample apps and documentation.
• Review cloud storage and identity permissions as part of every change, and scan infrastructure-as-code before deployment.
• Send security headers, disable directory listing and return generic error pages.
• Disable external entity processing in XML parsers.

DeepStrike deep dives. See our research on misconfigured Supabase instances at scale and on Firebase authentication misconfigurations, both common in modern web stacks. For cloud environments, cloud penetration testing covers the platform layer behind the application.

A03:2025 Software Supply Chain Failures

Definition. Software supply chain failures are compromises or weaknesses anywhere in the chain that builds and delivers your software: vulnerable or unmaintained dependencies, malicious packages, hijacked maintainer accounts, tampered build systems and compromised distribution channels. The category expands the 2021 "Vulnerable and Outdated Components" risk from known flaws to the whole ecosystem.

Why it is new. This was the community survey's top concern, with exactly 50% of respondents ranking it first. OWASP notes the category has limited presence in automated testing data, which it attributes to how hard it is to test, but the highest average exploit and impact scores from related CVEs.

Real examples. On March 29, 2024, CISA warned that malicious code had been embedded in XZ Utils versions 5.6.0 and 5.6.1, a compression library present in many Linux distributions. The backdoor, tracked as CVE-2024-3094, was hidden in the release tarballs and could allow unauthorized access to affected systems. In September 2025, CISA reported that a self-replicating worm known as "Shai-Hulud" had compromised more than 500 npm packages by stealing developer tokens and publishing infected versions.

How pentesters test for it. Supply chain testing starts with inventory. Testers identify client-side and server-side components and versions, compare them with vulnerability databases, and look for libraries loaded from third-party domains without integrity checks. When the CI/CD pipeline is in scope, they review who can change build definitions, how secrets are stored, whether package sources are pinned to trusted registries, and whether internal package names could be claimed on a public registry. Much of this work is review rather than exploitation, which is one reason the category is underrepresented in scanner data.

How to prevent it.

• Generate and maintain a software bill of materials (SBOM) that includes transitive dependencies.
• Remove unused dependencies, and monitor CVE, NVD and OSV data with software composition analysis.
• Install packages only from official sources, prefer signed packages, and pin versions.
• Protect developer and CI/CD accounts with phishing-resistant multifactor authentication, and rotate tokens after any suspected compromise.
• Treat build systems as production assets with their own access reviews.

DeepStrike deep dives. Our guide to software supply chain attacks explains attack types and detection in depth, and our secure SDLC guide shows where dependency and build controls fit in each phase of development.

A04:2025 Cryptographic Failures

Definition. Cryptographic failures cover the absence of encryption where it is needed and the misuse of cryptography where it exists: cleartext transmission, weak or outdated algorithms, poor randomness, unsalted or fast password hashes, hardcoded or leaked keys, and broken signature or certificate validation. These failures often lead directly to sensitive data exposure or system compromise.

Why it dropped. It fell from second to fourth, but it is far from rare: OWASP's data shows that on average 3.80% of applications had at least one of its 32 CWEs, slightly more than Broken Access Control's 3.73%.

Real example. Oracle's April 19, 2022 Critical Patch Update fixed CVE-2022-21449, nicknamed "Psychic Signatures." According to the Centre for Cyber Security Belgium, the ECDSA signature verification code introduced in Java 15 did not check that the signature values r and s were non-zero. A signature made of zeros could therefore validate, which let an attacker forge signatures and bypass authentication that relied on ECDSA, including JSON Web Tokens. Java 15 through 18 were affected.

How pentesters test for it. Testers check transport security (protocol versions, cipher suites, HSTS and any cleartext endpoints), how tokens and session identifiers are generated, and whether the application accepts tokens with invalid, missing or downgraded signatures in a test environment. In white-box or code-assisted tests they review password hashing, key storage, hardcoded secrets and the use of deprecated algorithms or modes. They also look for sensitive data that is cached, logged or returned when it does not need to be.

How to prevent it.

• Classify data and do not store sensitive data you do not need.
• Encrypt data in transit with TLS 1.2 or later and forward-secrecy cipher suites, and enforce HTTPS with HSTS.
• Store passwords with adaptive, salted hashing functions such as Argon2, yescrypt, scrypt or PBKDF2-HMAC-SHA-512.
• Use well-maintained cryptographic libraries, keep them patched, and keep the most sensitive keys in a hardware or cloud HSM.
• Reject tokens whose algorithm or signature does not match what the server expects.

DeepStrike deep dive. Our explainer on perfect forward secrecy covers why forward-secret key exchange limits the damage of a stolen server key.

A05:2025 Injection

Definition. Injection occurs when untrusted input is sent to an interpreter as part of a command or query, so the interpreter executes attacker-controlled instructions. The category includes SQL, NoSQL, OS command, LDAP and expression language injection, server-side template injection and cross-site scripting, where the browser is the interpreter.

Why it is still in the top five. Injection fell from third to fifth, yet OWASP calls it one of the most tested categories, with every application tested for some form of it and the greatest number of associated CVEs. Cross-site scripting alone accounts for more than 30,000 CVEs and SQL injection for more than 14,000. For how SQL injection works and how to prevent it, see our SQL injection guide.

Real example. According to a joint CISA and FBI advisory published June 7, 2023, the CL0P ransomware gang began exploiting a previously unknown SQL injection vulnerability in Progress MOVEit Transfer on May 27, 2023. The flaw, CVE-2023-34362, let unauthenticated attackers reach the application's database. Internet-facing MOVEit Transfer servers were infected with a web shell named LEMURLOOT, which was used to steal data.

How pentesters test for it. Testers map every input the application processes, including headers, cookies, JSON and GraphQL fields, file names and values that are stored and reused later. For each one they send benign probe values and watch for changes in errors, timing or output that show the input reached a query, command or template unescaped. For cross-site scripting they identify the output context (HTML body, attribute, JavaScript, URL) where each value is reflected or stored. In code-assisted tests they trace sources to sinks and flag string-built queries and shell calls. Confirmation stays within agreed limits, such as proving read access to a test record rather than extracting data.

How to prevent it.

• Use parameterized queries or safe APIs that keep data separate from commands, and remember that stored procedures can still concatenate input.
• Encode output for the exact context it lands in, and add a Content Security Policy as a second layer.
• Validate input against an allowlist on the server.
• Avoid shell calls with user input entirely where possible.
• Run database and service accounts with the least privilege they need.

DeepStrike deep dives. See our guides to server-side template injection and GraphQL API attacks, plus two disclosed case studies: SQL injection in SVX Portal and reflected XSS through an unescaped attribute. For XSS types and output encoding, see our cross-site scripting (XSS) guide.

A06:2025 Insecure Design

Definition. Insecure design is a missing or ineffective security control that should have been decided before any code was written. Examples include business logic that allows abusing discounts or limits, workflows that trust the client, weak tenant separation, unrestricted file uploads and race conditions. A perfect implementation of an insecure design is still insecure, so these flaws need design changes.

Why it moved down. Insecure Design slid from fourth to sixth as Security Misconfiguration and Software Supply Chain Failures overtook it. OWASP credits noticeable improvements in threat modeling since the category was introduced in 2021, and warns that insecure design is beyond the scope of most forms of testing.

Real example. CVE-2025-31324 was published on April 24, 2025. The Metadata Uploader in SAP NetWeaver Visual Composer was not protected with a proper authorization check, allowing an unauthenticated user to upload potentially malicious executable files to the host. NVD classifies it as CWE-434, unrestricted upload of a file with a dangerous type, which OWASP maps to A06. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on April 29, 2025. The case shows how a design decision (an upload feature reachable without authentication) overlaps with access control.

How pentesters test for it. Because design flaws do not show up as malformed input, testers start from the application's purpose. They review the threat model if one exists, then write abuse cases against key flows: skipping steps in a checkout or approval workflow, repeating an action faster than the business allows, changing quantities or prices the server should own, and sending parallel requests to expose race conditions. They also check whether file uploads restrict type, size, storage location and execution, and whether one tenant's actions can affect another's.

How to prevent it.

• Run threat modeling for authentication, access control, business logic and other critical flows.
• Build from secure design patterns and vetted "paved road" components.
• Write misuse cases next to use cases and turn them into unit and integration tests.
• Put plausibility checks and resource limits on every tier, not only in the user interface.
• Segregate tenants by design across all layers.

DeepStrike deep dives. Start with our threat modeling guide. For two design-level weaknesses OWASP maps to A06, see our explainers on HTTP request smuggling and time-of-check to time-of-use race conditions.

A07:2025 Authentication Failures

Definition. Authentication failures occur when an application cannot reliably confirm who a user is or protect the session afterward. Typical causes include allowing credential stuffing and brute force, weak or default passwords, missing or bypassable multifactor authentication, flawed password reset flows, hardcoded credentials, and session identifiers that are exposed, reused or never invalidated.

What changed. The category kept seventh place and dropped "Identification" from its name to match its 36 CWEs more accurately. OWASP notes that standardized authentication frameworks appear to be reducing occurrences, but the risk remains common.

Real examples. CVE-2024-1709, published February 21, 2024, was an authentication bypass in ConnectWise ScreenConnect 23.9.7 and earlier that used an alternate path (CWE-288). CISA's KEV entry describes it as letting an attacker with network access to the management interface create a new administrator-level account; CISA added it to the catalog the next day. In January 2024, CVE-2023-7028 showed the password reset variant: GitLab could send reset emails to an unverified address, enabling account takeover. NVD maps it to CWE-640, a weak password recovery mechanism, which sits in A07.

How pentesters test for it. Testers exercise every way into an account, not just the main login form: registration, login, MFA enrollment and challenge, password reset, "remember me," single sign-on and API tokens. Using test accounts, they check whether MFA can be skipped on an alternate endpoint, whether reset tokens are single-use, bound to the account and short-lived, whether rate limits and lockouts slow automated guessing, and whether session identifiers change after login and die after logout or timeout. For token-based sign-in they verify issuer, audience, expiry and signature validation.

How to prevent it.

• Enforce multifactor authentication, preferably phishing-resistant, on every path to an account.
• Never ship default credentials, and check new passwords against known-breached and common-password lists.
• Follow NIST SP 800-63B for password length and rotation rather than forced periodic changes.
• Rate-limit and monitor authentication attempts without creating a lockout-based denial of service.
• Generate new, random session identifiers after login and invalidate them on logout and timeout.

DeepStrike deep dives. See 2FA bypass techniques, our JWT account takeover case study and OAuth from a security perspective.

A08:2025 Software or Data Integrity Failures

Definition. Software or data integrity failures happen when an application trusts code, updates, serialized objects or critical data without verifying that they come from the expected source and have not been altered. Examples include insecure deserialization, unsigned updates, scripts loaded from untrusted origins, and frameworks that let users set object properties they should not control.

What changed. The category stayed eighth, with a small clarifying rename from "Software and Data" to "Software or Data." OWASP positions it at a lower level than A03: A03 is about the ecosystem, while A08 is about the trust boundaries inside your own application and pipeline. Its notable CWEs include CWE-502 (deserialization of untrusted data) and CWE-915, better known as mass assignment.

Real example. In July 2025, attackers exploited on-premises Microsoft SharePoint Server through an exploit chain publicly called "ToolShell." CVE-2025-53770, a deserialization of untrusted data flaw that let an unauthorized attacker execute code over the network and was a patch bypass for an earlier SharePoint CVE, was added to CISA's KEV catalog on July 20, 2025. CISA's alert on the SharePoint exploitation tracked the campaign as it expanded to web shells and ransomware.

How pentesters test for it. Testers look for serialized data that crosses a trust boundary, such as cookies, hidden fields, view state, message queues and API parameters, and check whether the application verifies a signature or integrity value before using it. In APIs they add properties that are not in the documented request, such as role or ownership fields, to see whether the server binds them. They also review update and plugin mechanisms, third-party scripts loaded without Subresource Integrity, and, where in scope, who can alter pipeline definitions and artifacts.

How to prevent it.

• Verify digital signatures on software, updates and critical data before use.
• Do not deserialize untrusted data with native object serializers; use simple data formats with strict schemas.
• Bind only explicitly allowlisted fields from requests to objects.
• Use Subresource Integrity for third-party scripts, or host them yourself.
• Require review for code and configuration changes, and segregate and access-control the CI/CD pipeline.

DeepStrike deep dives. Read our mass assignment guide and penetration testing for DevOps, which covers pipeline trust.

A09:2025 Security Logging and Alerting Failures

Definition. Security logging and alerting failures mean attacks go unrecorded or unnoticed. Logins, access control failures and high-value transactions are not logged, logs lack the context needed for investigation, logs leak sensitive data or can be tampered with, or nobody is alerted when suspicious activity occurs. Without detection, every other control failure lasts longer.

What changed. The category kept ninth place and was renamed from "Monitoring" to "Alerting" because, in OWASP's words, great logging with no alerting is of minimal value in identifying security incidents. It was voted onto the list by survey participants for the third time; it has only five CWEs and minimal representation in CVE data because it is so hard to test.

Real example. In mid-June 2023, a US federal civilian agency noticed MailItemsAccessed events with an unexpected application ID in its Microsoft 365 audit logs and reported them to Microsoft and CISA. The joint CISA and FBI advisory of July 12, 2023 explains that advanced persistent threat (APT) actors had used forged authentication tokens to read Exchange Online mail from a small number of accounts. The agency caught it because it had enhanced logging and a baseline of normal activity; CISA and the FBI said they were not aware of other audit logs or events that would have detected it.

How pentesters test for it. OWASP itself notes that testers can often only confirm whether they triggered incident response in a test environment, which is rarely monitored like production. The most useful approach is to coordinate with the defenders: agree on which test actions should be detected, then compare the attack timeline with what was logged and alerted. Testers also check whether security events carry enough context (user, source, object, outcome), whether logs record secrets or personal data, and whether user input written to logs is encoded to prevent log injection.

How to prevent it.

• Log authentication, access control and server-side validation failures with enough context to investigate, and keep logs long enough for delayed forensics.
• Give high-value transactions an audit trail with integrity protection.
• Encode log data, and never log passwords, tokens or full payment data.
• Turn important events into alerts with an owner, a threshold and a response playbook.
• Test detection regularly with joint exercises rather than assuming alerts work.

DeepStrike deep dives. Our guides to mean time to detect (MTTD), purple teaming and incident response planning cover how to measure and improve detection.

A10:2025 Mishandling of Exceptional Conditions

Definition. Mishandling of exceptional conditions covers how software behaves when something unexpected happens: a missing parameter, a malformed value, an exhausted resource, a failed dependency or an interrupted transaction. Weaknesses include detailed error messages that leak information, unchecked return values, NULL pointer dereferences, partial transactions that are not rolled back, and security checks that fail open.

Why it is new. OWASP created this category in 2025 with 24 CWEs, some of which were previously grouped under general code quality. Notable entries include CWE-209 (error message containing sensitive information) and CWE-636 (not failing securely, or "failing open").

Real example. CVE-2025-47813, published July 10, 2025, affects the web interface of Wing FTP Server before version 7.4.4. Sending an overly long value in the UID cookie to the loginok.html page caused the server to disclose the application's full local installation path. CISA's KEV entry classifies it as CWE-209 and was added on March 16, 2026, meaning there was evidence of exploitation in the wild. An installation path is exactly the kind of detail attackers use when chaining other flaws.

How pentesters test for it. Testers deliberately send the application into unusual states in a test environment: parameters that are missing, duplicated, empty, oversized or of the wrong type; requests that interrupt multistep transactions halfway; and dependency failures where they can be simulated. They then check three things. Does the response leak stack traces, file paths, queries or versions? Does the transaction roll back completely? When a security component such as an authorization service or token validator errors out, does the application deny the request or let it through?

How to prevent it.

• Catch errors where they occur and handle them meaningfully, with a global exception handler as a backstop.
• Return generic messages to users and log the detail server-side.
• Fail closed: if a security check cannot complete, deny the action.
• Roll back multistep transactions completely on error, and release resources reliably.
• Monitor for bursts of errors that suggest someone is probing your error handling.

DeepStrike deep dives. There is no dedicated DeepStrike guide to this new category yet. Our overview of the most common web application vulnerabilities covers related information disclosure issues.

How Pentesters Test Across the OWASP Top 10

No single tool or test type covers the whole list. OWASP says so directly: tools cannot comprehensively detect, test or protect against the Top 10 because some risks, such as insecure design, are not testable by tooling, and OWASP discourages any claim of full coverage. The table below shows where each technique tends to find each category. It is DeepStrike's editorial guidance for planning, not an OWASP mapping.

Three patterns stand out. Access control, authentication and business logic flaws (A01, A06 and A07) depend on understanding what each user should be allowed to do, which is why manual testing finds them far more reliably than scanners. Supply chain risk (A03) is mostly a dependency and pipeline review problem. Logging and alerting (A09) can only be proven by checking whether defenders actually saw the test. For a broader comparison of testing approaches, see our guide to SAST vs DAST vs IAST vs RASP and our penetration testing methodology.

The OWASP Top 10 Is Not a Testing Standard

OWASP describes the Top 10 as primarily an awareness document and says that if you use it as a coding or testing standard, it is "the bare minimum and just a starting point." For requirements and test cases, use the OWASP projects designed for that job:

The resources are at asvs.owasp.org, the Web Security Testing Guide, the OWASP API Security Top 10 2023 and the OWASP Cheat Sheet Series. DeepStrike covers the AI list in our OWASP LLM Top 10 guide, API risk data in our API security statistics, and API tooling in our review of API security testing tools.

A practical way to combine them: use the Top 10 to explain risk and set priorities, ASVS to define what "secure enough" means for each application, and WSTG to drive the test plan. For the controls behind each category and how ASVS levels work, see our web application security guide.

Risks Just Outside the 2025 List

OWASP also published three "next steps" risks that were considered but did not make the final ten. They are worth adding to threat models and test scopes now:

• X01:2025 Lack of Application Resilience. A renaming of 2021's Denial of Service, focused on root causes such as uncontrolled resource consumption. OWASP says its score was very close to A10.
• X02:2025 Memory Management Failures. Buffer overflows, use-after-free and similar flaws, which matter most in components written in memory-unsafe languages.
• X03:2025 Inappropriate Trust in AI Generated Code ("Vibe Coding"). Accepting AI-generated code without the review, testing and security checks applied to human-written code.

The full descriptions are on OWASP's Next Steps page.

Common Mistakes When Using the OWASP Top 10

• Treating a clean scan as "OWASP compliant." Scanners miss most access control, design and business logic flaws, and OWASP itself rejects full-coverage claims.
• Keeping 2021 labels in reports and tickets. Map SSRF findings to A01:2025 and outdated component findings to A03:2025 so trends stay comparable.
• Testing one role. Access control flaws only appear when testers compare at least two users per role and across roles and tenants.
• Ignoring the categories that are hard to test. A03, A06 and A09 need review, threat modeling and detection exercises, not only dynamic testing.
• Fixing the instance, not the cause. Each finding should lead to a shared fix, such as a central authorization check or a safe query API, and a regression test.

For a wider list that goes beyond the Top 10 categories, see our guide to the 20 most common web application vulnerabilities.

Frequently Asked Questions

What is the OWASP Top 10?

The OWASP Top 10 is a free awareness document from the OWASP Foundation that ranks the ten most critical security risk categories for web applications. It is built from vulnerability data contributed by organizations plus a practitioner survey, and it is widely used for developer training, testing scopes and security policies.

What are the OWASP Top 10 2025 vulnerabilities?

The ten categories are A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions.

When was the OWASP Top 10 2025 released?

OWASP released the 2025 edition in November 2025, planned around its Global AppSec USA conference in Washington, D.C. It was the first update since 2021, and OWASP now lists 2025 as the current version and 2021 as superseded.

Is there an OWASP Top 10 for 2026?

No. As of November 2026, the 2025 edition is the current web application list. Recent editions appeared in 2017, 2021 and 2025, so a new web list in 2026 would be unusual. OWASP's separate Top 10 for LLM Applications follows its own release schedule.

What is new in the OWASP Top 10 2025?

Two categories are new: A03 Software Supply Chain Failures, which expands the 2021 Vulnerable and Outdated Components category, and A10 Mishandling of Exceptional Conditions. Server-Side Request Forgery was merged into A01 Broken Access Control, Security Misconfiguration rose from fifth to second, and three categories were renamed.

Is the OWASP Top 10 2021 still valid?

The 2021 list remains published for reference, but OWASP marks it as superseded. Use the 2025 categories for new policies, training, scanner rules and penetration test scopes, and map older findings to their 2025 equivalents.

Does the OWASP Top 10 cover APIs and AI applications?

The web Top 10 applies to APIs that sit behind web applications, but API-specific risks are better covered by the OWASP API Security Top 10 (2023 edition). Large language model applications have their own OWASP Top 10 for LLM Applications.

Is the OWASP Top 10 a compliance requirement?

The Top 10 is an awareness document, not a regulation or certification. Many organizations, customers and auditors still use it as a baseline for secure development and testing scopes. OWASP recommends ASVS when you need a verifiable standard.

Next Step: Test Your Application Against the 2025 Categories

The fastest way to learn where your application stands is to test it the way an attacker would, with every role, every tenant and every business flow in scope. DeepStrike's web application penetration testing combines automated coverage with manual testing that covers the OWASP Top 10, checks access from multiple users' perspectives and reports only vulnerabilities validated through exploitation. Each engagement includes fix recommendations, re-testing to confirm remediation and an attestation letter. To scope a test, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• OWASP Top 10:2025 (official list)
• OWASP Top 10:2025 Introduction: what changed and methodology
• OWASP Top 10:2025 category pages A01 to A10
• OWASP Top 10:2025: Establishing a Modern Application Security Program
• OWASP Top 10:2025: Next Steps
• OWASP Top 10:2021
• OWASP Top 10 project page
• OWASP Top 10 GitHub repository
• Microsoft: HAFNIUM targeting Exchange Servers with 0-day exploits (March 2, 2021)
• Microsoft Security Response Center: overly permissive SAS token exposure (September 18, 2023)
• CISA: Reported Supply Chain Compromise Affecting XZ Utils, CVE-2024-3094 (March 29, 2024)
• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem (September 23, 2025)
• Centre for Cyber Security Belgium: Advisory 2022-009 on CVE-2022-21449
• CISA and FBI: AA23-158A, CL0P Exploits CVE-2023-34362 MOVEit Vulnerability (June 7, 2023)
• CISA: Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities (July 20, 2025, updated)
• CISA and FBI: AA23-193A, Enhanced Monitoring to Detect APT Activity Targeting Outlook Online (July 12, 2023)
• NVD records: CVE-2021-26855, CVE-2024-3094, CVE-2022-21449, CVE-2023-34362, CVE-2025-31324, CVE-2024-1709, CVE-2023-7028, CVE-2025-53770, CVE-2025-47813
• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide
• OWASP API Security Top 10 2023
• OWASP Cheat Sheet Series