OWASP Top 10:2025 for web application pentests: what changes and what we test

The OWASP Top 10 has been the most cited reference for web application security for more than twenty years. January 2026 saw the release of the 2025 edition: the first major content revision since 2021. OWASP based the list on an analysis of more than 175,000 CVE records and almost 600 underlying weakness classes (CWEs), supplemented by a community survey for risks not yet broadly visible in the data. For anyone commissioning a web application pentest, or preparing the scope for one, it is worth understanding what has changed and how a pentester tests these categories in practice.

In this article we walk through the ten 2025 categories from the pentester's perspective: what each category means, how we attack it during a web application pentest, and the type of finding you can expect in a report. We close with the relationship between the OWASP Top 10 and a full pentest, because that causes a lot of confusion in practice.

What changed compared to 2021

The biggest changes are two new categories and several re-rankings. Software Supply Chain Failures (A03) is new and replaces and broadens the old 'Vulnerable and Outdated Components' category. The focus shifts from individual vulnerable libraries to the entire supply chain: build pipelines, package repositories, transitive dependencies, and the integrity of what ultimately runs in production. Mishandling of Exceptional Conditions (A10) is also new and concerns how applications deal with errors, exceptions, and unexpected input. In addition, Server-Side Request Forgery is no longer a separate category but has been absorbed into Broken Access Control, and several categories were renamed. Broken Access Control remains firmly at number one.

A01 — Broken Access Control

Broken access control is once again the most common and often the most impactful problem. It is about a user being able to do or see something they have no right to. In a pentest this is usually our first and most productive line of attack. We create two accounts with different privileges and systematically test whether user A can reach user B's data. Classic examples include incrementing an object ID in the URL (insecure direct object reference), directly accessing an admin function without the correct role, and manipulating a hidden form field that determines the price or the user role. Since 2025, SSRF also falls under this category: abusing the server to reach internal systems or cloud metadata endpoints.

A02 — Security Misconfiguration

Misconfiguration is broad and pervasive. Default passwords left unchanged, verbose error messages exposing stack traces, unused ports and services, overly permissive CORS settings, and missing security headers. During a pentest we map the presence and quality of headers such as Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options, check for exposed admin interfaces, and look for directory listing and leftover debug functionality. These are often low-hanging findings that are easy to fix, but together they significantly enlarge the attack surface.

A03 — Software Supply Chain Failures

The new supply chain category acknowledges that modern applications consist largely of third-party code. A vulnerability in a widely used library, a compromised npm package, or an insecure build pipeline can undermine an otherwise solidly built application. In our assessment we look at known vulnerabilities in dependencies (via a software bill of materials), at how dependencies are pinned and verified, and at the security of the pipeline itself. For organizations this is the moment to set up an SBOM process and take the provenance of external components seriously, not just their own code.

A04 — Cryptographic Failures

This category concerns the protection of sensitive data, both in transit and at rest. Think of missing or weak encryption, outdated TLS configurations, weak password hashing algorithms, and leaking sensitive data in URLs or logs. In a pentest we check TLS settings, verify that cookies carry the Secure and HttpOnly attributes, and look for sensitive information transmitted or stored without encryption.

A05 — Injection

Injection covers SQL injection, command injection, and cross-site scripting (XSS), which has been part of this category since 2021. The common thread is that user input is insufficiently separated from commands or queries. We test input fields, URL parameters, headers, and API payloads with context-appropriate payloads and assess whether the application uses parameterized queries and correct output encoding. A successful SQL injection remains among the most serious findings, as it often means direct access to the database.

A06 — Insecure Design

Insecure design is fundamentally different from an implementation flaw: the problem lies in the design itself, not in the code. A password reset process without rate limiting, a payment flow where the price is set client-side, or the absence of a countermeasure against automated abuse. These weaknesses are not found by a scanner; they require understanding of the business logic. This is where the value of an experienced pentester becomes clear, and where the bridge to threat modeling early in development lies.

A07 — Authentication Failures

Authentication and session weaknesses concern proving identity and managing sessions. We test for weak password policies, lack of protection against credential stuffing and brute force, predictable or non-rotated session tokens, and missing multi-factor authentication on sensitive functions. We also check whether sessions are properly invalidated on logout and whether tokens do not leak through improper storage.

A08 — Software or Data Integrity Failures

This category is about trusting code and data without verifying integrity. Think of insecure deserialization, auto-updates without signature verification, and CI/CD processes that deploy unverified artifacts. We assess whether the application trusts external data without checks and whether the path from code to production includes integrity controls.

A09 — Security Logging and Alerting Failures

Insufficient logging and alerting makes it hard to detect and respond to attacks. It is a category you do not always visibly 'break' in a pentest, but do assess: are login attempts, access failures, and suspicious actions recorded, and does that lead to timely alerting? The 2025 edition explicitly includes alerting in the name, because logging without follow-up has little value.

A10 — Mishandling of Exceptional Conditions

The second new category concerns how applications handle errors and edge cases. Poor error handling can leak information through error messages, cause fail-open behavior where a failed check still grants access, and produce unexpected behavior on invalid input. During a pentest we deliberately send unexpected and malformed input to see how robustly the application responds and whether errors are handled safely (fail-closed).

The OWASP Top 10 is not a pentest checklist

A persistent misconception is that 'testing against the OWASP Top 10' equals a full pentest. It does not. The Top 10 is an awareness document listing the ten most common risk categories, not a complete testing standard. A serious web application pentest follows broader frameworks such as the OWASP Web Security Testing Guide (WSTG) or the Application Security Verification Standard (ASVS), which contain hundreds of concrete test cases. The Top 10 is an excellent starting point and communication tool toward management, but a report limited to the Top 10 misses a lot of context, such as application-specific business logic flaws that fall outside any category.

From finding to remediation and retest

The value of a pentest lies not in the list of findings but in what happens afterward. A good report describes, for each finding, the impact, the exploitability, and concrete remediation advice, with prioritization based on risk rather than a CVSS score alone. After remediation comes a retest: a targeted recheck of whether the vulnerabilities are actually and fully resolved. We provide a retest as standard within an agreed period, because a finding is only closed once it is verifiably gone.

Secure Audit performs web application pentests combining automated tooling with manual expertise, with reporting that aligns with both the OWASP Top 10 and the deeper WSTG/ASVS test cases. Get in touch for a no-obligation conversation about the scope of a pentest for your application.