Insights · Application security guide

The OWASP Top 10 explained: what it is and what to ask providers

The OWASP Top 10 is a ranked list of the most critical web application security risks. The current edition is the 2025 edition, which replaced the 2021 list. It is a good shared vocabulary for buyers and engineers, but it is an awareness document and not a full security standard.

Updated: 6 November 2026

What the OWASP Top 10 is and which edition counts

OWASP, the Open Worldwide Application Security Project, is a non-profit community that publishes free security material. Its Top 10 names the ten risk categories that matter most for web applications. The 2025 edition is the one published on owasp.org today; it is the eighth installment and replaces the 2021 list. According to OWASP, the 2025 data set covers more than 2.8 million applications and 589 weakness types (CWEs), and two categories were added based on a community survey rather than data alone.

Each category bundles many individual weaknesses. That is why the list works well in contracts and reports: you can say that a test covered 'Injection' or 'Broken Access Control' and everyone knows roughly what is meant.

The ten categories in plain words

Here are the 2025 categories in ranked order, each with a typical example. Fixes are listed in the next section.

• A01 Broken Access Control: users can see or change things they should not. Example: changing an account number in a web address shows another customer's data. Server-Side Request Forgery is now part of this category.
• A02 Security Misconfiguration: systems are set up unsafely. Example: an admin console with the default password, or cloud storage open to the internet. It rose from fifth to second place.
• A03 Software Supply Chain Failures: a broken or compromised build, update or dependency chain. Example: a malicious package version pulled in automatically. This widens the older 'vulnerable and outdated components' category.
• A04 Cryptographic Failures: sensitive data is not protected properly. Example: personal data sent or stored without strong encryption.
• A05 Injection: untrusted input is run as a command or query. Example: SQL injection through a search field, or cross-site scripting.
• A06 Insecure Design: the flaw is in the concept, not the code. Example: a password reset flow that can be abused no matter how cleanly it is programmed.
• A07 Authentication Failures: login and session handling can be bypassed. Example: no protection against password guessing, or sessions that never expire.
• A08 Software or Data Integrity Failures: code or data is trusted without checking it. Example: an update mechanism that does not verify signatures.
• A09 Security Logging and Alerting Failures: attacks go unnoticed because events are not logged or nobody gets alerted.
• A10 Mishandling of Exceptional Conditions: the new category. The software fails badly under unusual situations. Example: detailed database errors that help an attacker, or a half-finished transaction that is not rolled back.

How to prevent the biggest risks

OWASP gives concrete guidance per category. A few themes repeat. For access control, enforce rules on the server, deny by default, check that a record belongs to the user, and log failures. For misconfiguration, use an automated, repeatable hardening process, remove unused features, and keep separate credentials per environment.

For supply chain risk, keep a software bill of materials (SBOM) that includes indirect dependencies, scan components continuously, use trusted sources and signed packages, and protect the build pipeline as carefully as production. For exceptional conditions, handle errors where they occur, show users harmless messages, roll back incomplete transactions completely, and rate-limit abusive behavior.

For the remaining categories, the usual measures apply: modern encryption with sound key handling, parameterized queries and output encoding against injection, threat modeling during design, multi-factor authentication, signed updates, and central logging with alerts someone actually reads.

Why the Top 10 is not a standard

OWASP describes the Top 10 as primarily an awareness document. Many organizations treat it as an industry standard anyway, but OWASP itself calls it a bare minimum and a starting point. It ranks risks; it does not list testable requirements.

For requirements, OWASP points to the Application Security Verification Standard (ASVS). The current version is ASVS 5.0.0, released on 30 May 2025. It is a catalog of security requirements for designing, building and testing web applications and services, and its stated uses include procurement contracts. If you buy or commission software, 'meets ASVS at a stated level' is a far more precise requirement than 'is secure against the OWASP Top 10'.

How to test against it

No single method covers all ten categories. Static analysis (SAST) reads source code and finds many injection and configuration problems early, but it cannot judge whether the right events are logged. Dynamic testing (DAST) attacks the running application from outside and finds exposed errors, missing headers and some access problems. Software composition analysis checks dependencies for known flaws and supports the supply chain category.

A manual penetration test is what finds broken access control and business-logic abuse, because a person must understand what each user role is supposed to do. Insecure design is hard to test at all; OWASP notes that it is beyond the scope of most forms of testing, so design reviews and threat modeling are needed. OWASP also suggests at least annual penetration testing, depending on the assurance level you need.

Treat scanners as a routine safety net and the pentest as a periodic deep check. Neither replaces secure development practices.

Related OWASP lists

Two other lists are often confused with the web Top 10. The OWASP API Security Top 10 focuses on interfaces; its current edition on the project site is the 2023 edition, with entries such as broken object level authorization and unrestricted resource consumption. The OWASP Top 10 for LLM Applications covers AI-specific risks; its current edition is 2025 and includes prompt injection, sensitive information disclosure and excessive agency. If your product exposes APIs or embeds a language model, ask for coverage of these lists as well.

What to ask a provider

Whether you hire developers, a pentest team or a managed vulnerability service, these questions separate substance from slogans.

• Which edition of the OWASP Top 10 and which ASVS version and level do you work against?
• Which categories do you test manually and which only with tools?
• How do you test access control for different user roles?
• Do you deliver an SBOM and check dependencies and the build pipeline?
• Does the report map each finding to a category and give reproducible steps and a fix recommendation?
• Is a retest included after we fix the findings?
• How are design reviews or threat modeling handled before code is written?