Guide

OWASP Top 10 2025: All Ten Categories and What Changed

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

The OWASP Top 10 2025 is the current edition of the best-known list of critical security risks for web applications. It runs from A01 Broken Access Control to A10 Mishandling of Exceptional Conditions and replaces the 2021 edition. The main changes: two new categories, Software Supply Chain Failures and Mishandling of Exceptional Conditions, and Server-Side Request Forgery folded into Broken Access Control.

Status: final, first released as a release candidate on 6 November 2025

OWASP (Open Worldwide Application Security Project) released the Top 10 2025 as a release candidate on 6 November 2025. That date comes from the notice the project kept in its introduction until the end of 2025. On 24 December 2025 the release candidate notice was removed from the official GitHub repository. The project page now calls the Top 10 2025 "the most current released version". It does not give a separate date for the final edition (as of 28 Oct 2026).

One name changed between the release candidate and the final text: A09 was called "Logging & Alerting Failures" in the draft and was renamed "Security Logging & Alerting Failures" in December 2025. Material written in November 2025 may still use the old name.

On methodology, OWASP says eight of the ten categories are based on test data contributed by organisations, covering more than 2.8 million applications by its own account. Two categories come from a community survey, because some risks rarely show up in automated testing. Each category groups several CWE entries, the weakness types catalogued by MITRE, and OWASP deliberately groups them by root cause rather than symptom.

The ten categories at a glance

The testing notes below apply to systems you own or have written permission to test. Testing third-party systems without authorisation is not acceptable.

A01:2025 Broken Access Control

What it means. Access control decides who may see which data and use which functions. When it is missing or can be bypassed, a user sees or changes other people's records or reaches admin functions. New in this category is Server-Side Request Forgery (SSRF): the application can be made to send requests to internal systems on the attacker's behalf. In 2021, SSRF was a category of its own (A10:2021).

Example. An invoice lives at /api/invoices/1043. A logged-in customer changes the number to 1044 and gets someone else's invoice. OWASP calls this an insecure direct object reference.

How to test. Use two test accounts with the same role and one with fewer rights. Put IDs from account A into requests made as account B, call admin URLs as a normal user and with no session at all, and try POST, PUT and DELETE as well as GET. For SSRF, find every feature that accepts a URL, such as image import or webhooks, and check whether it can reach internal addresses. Automated scanners rarely catch these flaws because they do not know which data belongs to whom.

A02:2025 Security Misconfiguration

What it means. A system is configured insecurely: default accounts are still active, error pages reveal internals, unnecessary services are running, security headers are missing. OWASP also files XML External Entities (XXE) here. The category rose from 5th to 2nd place, which OWASP attributes to more and more application behaviour being driven by configuration.

Example. A cloud storage bucket with customer documents is publicly readable, or a framework runs in debug mode and returns the full stack trace, paths included, when something fails.

How to test. Read the response headers your application actually serves. Here is what that looks like on our own website, measured with a GET request on 28 Oct 2026:

$ curl -s -D - -o /dev/null https://www.cybersec42.com/
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'sha256-…'; …
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=(), interest-cohort=()

A missing header is a pointer, not proof of a vulnerability. Also check default passwords, exposed admin panels, directory listings, verbose error messages and the sharing settings of storage and databases in your cloud console.

A03:2025 Software Supply Chain Failures

What it means. Most of your application is other people's code: libraries, container images, build tools, extensions. This category widens 2021's "Vulnerable and Outdated Components" to everything that can go wrong while building, distributing and updating software, up to and including the CI/CD pipeline. According to OWASP it appears rarely in the test data but was voted a top concern by a wide margin in the survey. OWASP suspects the reason is that it is still hard to test for.

Example. A package in a public registry is republished with malicious code, and the next build pulls it in unchecked. Or a known flaw in a bundled library stays unpatched for months because nobody knows it is in use.

How to test. Generate a software bill of materials (SBOM), including transitive dependencies, and match it against known vulnerabilities with tools such as npm audit, pip-audit or OWASP Dependency-Check. Pin versions with a lockfile. In the pipeline, ask who can push code all the way to production without a second person approving it, and which secrets the build can see.

A04:2025 Cryptographic Failures

What it means. Sensitive data is sent or stored unencrypted, encrypted with outdated algorithms, or protected by poorly managed keys. OWASP's list includes deprecated hash functions such as MD5 or SHA1, reused keys, keys committed to source code and missing certificate validation.

Example. Passwords are stored as plain SHA1 hashes. After a breach, large numbers of them can be cracked.

How to test. Check the TLS configuration of your own server with a tool such as testssl.sh. Search code and version history for keys, for example with gitleaks. Find out how passwords are stored: it should be a purpose-built algorithm such as Argon2, scrypt or bcrypt, not a general-purpose hash.

A05:2025 Injection

What it means. Untrusted input reaches an interpreter, such as the database, the shell or the browser, and is executed as a command. This covers SQL injection and cross-site scripting (XSS). OWASP describes XSS as high frequency and lower impact, SQL injection as lower frequency and high impact. The category drops from 3rd to 5th but remains one of the most tested.

Example. A search box concatenates the input straight into a SQL query. An apostrophe produces a database error; a crafted input reads other tables.

How to test. Look for string-built queries and commands in the code; parameterised queries are the safe pattern. Test every input, not just form fields: URL parameters, headers, cookies, JSON. Static analysis (SAST) and dynamic scanners (DAST) in the pipeline reliably catch part of this class. OWASP explicitly covers prompt injection in language models in a separate list, see AI lists compared.

A06:2025 Insecure Design

What it means. The weakness is in the design, not the implementation. Flawless code does not help if the necessary control was never planned. OWASP deliberately separates insecure design from insecure implementation because the root causes and fixes differ. The category was introduced in 2021 and slips from 4th to 6th.

Example. A voucher code can be redeemed any number of times because nobody specified that it is single use. Or a password reset relies on security questions whose answers are on social media.

How to test. For security-relevant flows such as payment, sign-up or granting permissions, write a short threat model: what must not happen, and what stops an attacker from making it happen? OWASP itself notes that this category is beyond the scope of most forms of testing. Manual business logic testing is what helps here.

A07:2025 Authentication Failures

What it means. The application accepts someone as a legitimate user who is not. Causes include no protection against automated password guessing, weak password rules, insecure password recovery, missing multi-factor authentication, or sessions that stay valid after logout. The name was shortened; in 2021 it was "Identification and Authentication Failures".

Example. An attacker replays username and password pairs from other breaches against your login (credential stuffing). Without rate limiting, some of them work.

How to test. Trigger a run of failed logins and see whether the application slows down or locks the account. Check that the session ID changes after login and is invalid after logout. Walk through the forgot-password flow step by step. For tokens such as JWTs, check that expiry, issuer and audience are validated.

A08:2025 Software or Data Integrity Failures

What it means. Code or data is treated as trusted without verifying its origin or that it has not been changed. OWASP separates this from A03 by level: it sits lower down, at individual artefacts, data and trust boundaries. Examples are insecure deserialisation, updates without signature checks and scripts loaded from third-party servers without integrity checks.

Example. A page loads a script from a third-party CDN without Subresource Integrity. If the file is modified there, the modified code runs for every visitor.

How to test. Find every external script in the served HTML and check that it carries an integrity attribute. Search the code for deserialisation of data that comes from outside, such as cookies or uploads. Check that updates and build artefacts are signed and verified before use.

A09:2025 Security Logging & Alerting Failures

What it means. Attacks leave no trace, or the trace triggers no response. The new name puts alerting ahead of monitoring. OWASP's point, in short: great logging with no alerting is of little value for spotting incidents. Like A03, this category was voted in by the survey because it barely shows in test data.

Example. An attacker tries thousands of passwords over several days. The failures are not logged, or they are logged but nobody gets notified.

How to test. Check that failed logins, permission changes and high-value transactions are logged, and that no passwords or health data end up in the logs. Then trigger an alert on purpose: does it arrive, and does someone know what to do? OWASP names it as a warning sign when a penetration test or a DAST scan does not trigger any alert.

A10:2025 Mishandling of Exceptional Conditions

What it means. This category is new. It covers poor handling of unusual situations: missing or incomplete error handling, logic errors, race conditions and above all systems that fail open instead of failing closed. OWASP describes three failings: the application does not prevent the unusual situation, does not detect it, or responds badly to it.

Example. One scenario from the OWASP text: a transfer first debits one account, then credits the other, then logs the transaction. If the process breaks halfway and is not fully rolled back, the result is an inconsistent state an attacker can exploit.

How to test. Provoke errors on purpose: unexpected data types, empty or very large values, dropped connections, parallel requests against the same operation. Then check whether the state is consistent, whether the error message exposes internals, and whether a failed check denies access rather than granting it.

What changed compared with 2021

OWASP sums up the update as two new categories and one consolidation. On top of that, several categories moved and two were renamed.

In practice, if your testing was aligned with the 2021 edition, there are three gaps to close. The supply chain and build pipeline are now explicitly in scope, error handling gets tested in its own right, and SSRF testing continues under access control rather than dropping off the list.

Web list, AI lists and API list

Several lists now carry the "OWASP Top 10" name. This article covers the classic web application list. For applications built on language models there is the OWASP Top 10 for LLM Applications, for autonomous AI agents the OWASP Top 10 for Agentic AI, and for Model Context Protocol servers the OWASP MCP Top 10. APIs have their own OWASP API Security Top 10, which our API pentesting checklist walks through step by step.

The lists complement each other. A chatbot inside your web application carries the risks of the web list, such as broken access control, plus those of the LLM list, such as prompt injection.

What the list is not

OWASP itself calls the Top 10 an awareness document. It is not meant to be complete, only a starting point. Three consequences are easy to miss.

• Not a testing standard. If you use the Top 10 as a coding or testing standard, OWASP says that is "the bare minimum". The list describes risks, not testable requirements. For verifiable requirements OWASP recommends the Application Security Verification Standard (ASVS). The current stable release is ASVS 5.0.0, published on 30 May 2025.
• Not fully covered by any tool. OWASP states plainly that tools cannot comprehensively detect, test or protect against the Top 10, and discourages any claim of full coverage. A scanner cannot tell you whether your design is sound or your alerting works.
• Not a ranking of your risks. The order reflects data across a very large number of applications plus a survey. For your application, A10 may matter more than A01. Which risks count for you depends on your data, users and workflows.

For test methodology there is the OWASP Web Security Testing Guide (WSTG). The three documents split the work: the Top 10 tells you what to watch for, the ASVS what must be in place, the WSTG how to test it.

The Top 10 in a penetration test

In a web application penetration test, the Top 10 works as a shared vocabulary. Findings can be mapped to a category, and management and engineering quickly understand what kind of problem they are dealing with. As a test scope it falls short. The most consequential findings often sit where a scanner cannot judge: access control between tenants (A01), business logic (A06) and error states (A10). Those are tested by hand, with several test accounts.

A report that holds up therefore maps every finding to a category, backs it with reproducible proof and states openly which categories were not tested, or only partly, within the agreed scope, for instance A09 when there was no access to monitoring. How such a test runs and what drives the effort is covered in Penetration Testing: Process, Duration and Cost.

Frequently asked questions

Further reading

• API Pentesting Checklist: OWASP API Top 10
• Penetration Testing: Process, Duration and Cost
• OWASP Top 10 for LLM Applications, Explained
• Service: Penetration testing

Sources

• OWASP Top 10:2025
• OWASP Top 10:2025, Introduction (changes and methodology)
• OWASP Top 10:2025, Establishing a Modern Application Security Program (using the Top 10 as a standard)
• OWASP Top 10:2025, A01 Broken Access Control
• OWASP Top 10:2025, A10 Mishandling of Exceptional Conditions
• OWASP Top 10, GitHub repository (version history, release candidate notice)
• OWASP Top Ten, project page
• OWASP Top 10:2021
• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide (WSTG)