OWASP Top 10: The Web Application Risks Explained

The OWASP Top 10, sometimes written OWASP Top Ten, is a ranked list of the ten most critical security risk categories for web applications, published free by the Open Worldwide Application Security Project (OWASP). The current edition is the OWASP Top 10:2025, which replaced the 2021 list. It is the shared vocabulary of web security: developers build against it, and testers use it as the minimum a web application test should cover.

What is the OWASP Top 10?

It is an awareness document, not a certifiable standard. Each entry groups related weaknesses (catalogued as CWEs), so “Injection” covers SQL injection, command injection and cross-site scripting together.

The 2025 list was built from testing firms’ and tool vendors’ data on more than 2.8 million applications, plus a community survey for risks the data does not yet show well: eight categories come from the data and two from the survey. The full text is on the OWASP Top 10 project page.

What are the OWASP Top 10 vulnerabilities in 2025?

Strictly, each entry is a category of related weaknesses rather than a single vulnerability. These are the ten in the current list:

Each category in more detail, with how a penetration tester checks for it:

A01:2025 Broken Access Control

Users can read, change or delete data, or use functions, outside their permissions. The category covers insecure direct object references (IDOR), missing checks on admin functions, privilege escalation and, since 2025, server-side request forgery (SSRF), where the application is tricked into fetching internal resources for the attacker.

How it’s tested: the tester logs in as each role you provide, replays requests with another user’s IDs and session, calls admin functions as an ordinary user and points URL parameters at internal addresses. A scanner cannot judge who should see what, so this is manual work.

A02:2025 Security Misconfiguration

Secure software deployed insecurely: default accounts, verbose error messages, directory listing, missing security headers, unnecessary features and publicly readable cloud storage. It rose from fifth to second place in 2025.

How it’s tested: checks of security headers, error handling, default content and credentials, TLS settings and exposed admin interfaces, plus cloud storage permissions where they are in scope. Much of this suits automated scanning, with each result confirmed by hand.

A03:2025 Software Supply Chain Failures

Weaknesses that come from what you build on rather than what you write: vulnerable or abandoned libraries, compromised packages, insecure build pipelines and unsigned releases. It widens the 2021 category Vulnerable and Outdated Components to cover the whole chain.

How it’s tested: the tester fingerprints frameworks and libraries and checks their versions against known vulnerabilities. A source code review adds a full dependency inventory and a look at build and deployment settings.

A04:2025 Cryptographic Failures

Sensitive data exposed because encryption is missing, weak or misused: plain HTTP, outdated TLS, weak password hashing, hard-coded keys or predictable random values.

How it’s tested: TLS configuration checks, a look at how passwords, tokens and session IDs are generated and stored, and searches for sensitive data in URLs, caches, logs and responses.

A05:2025 Injection

Untrusted input that the application passes to an interpreter as code or a command, including SQL, NoSQL, OS command and LDAP injection and cross-site scripting. Parameterised queries and context-aware output encoding prevent most of it.

How it’s tested: every input, header and API parameter is probed, with automated tools for breadth and manual work to confirm each finding and show its real impact, such as reading data through a SQL injection.

A06:2025 Insecure Design

Flaws that exist because a control was never designed in, such as unlimited password reset attempts, a checkout that trusts the price the browser sends, or a workflow whose steps can be skipped. Clean code cannot fix a control that was never there.

How it’s tested: business logic testing. The tester learns how each workflow is meant to work, then skips steps, repeats them, changes values and sends requests in parallel to break its assumptions. Threat modelling catches the same flaws earlier, at design time.

A07:2025 Authentication Failures

Weak login, session and recovery handling that lets an attacker take over accounts: no defence against credential stuffing or brute force, weak password rules, sessions that never expire, and reset flows that leak tokens or rely on guessable answers.

How it’s tested: the tester attacks login, multi-factor authentication, password reset and session handling directly, checking lockout and rate limits, session expiry and logout, and whether the second factor can be bypassed.

A08:2025 Software or Data Integrity Failures

Code, updates or data trusted without checking that they are genuine and unchanged, such as insecure deserialisation of objects sent by the client, updates installed without signature checks, or scripts loaded from third-party sites without integrity checks.

How it’s tested: the tester looks for serialised objects and signed data that can be altered, and checks how updates and third-party scripts are loaded. Where code access is given, the review extends to integrity controls in the build pipeline.

A09:2025 Security Logging and Alerting Failures

Attacks that go unnoticed because security events are not logged, logs are not protected or nobody is alerted. OWASP renamed it in 2025 to stress alerting, because a log nobody reviews does not stop a breach.

How it’s tested: only partly, by a penetration test. Testers record when their noisier attacks ran so your team can check whether logs captured them and alerts fired. A red team exercise tests detection and response properly.

A10:2025 Mishandling of Exceptional Conditions

New in 2025. It covers what happens when things go wrong: errors that reveal stack traces or data, transactions left half complete, and logic that fails open, granting access when a check throws an error instead of denying it.

How it’s tested: the tester sends malformed, oversized, missing and out-of-order input, interrupts multi-step processes and forces timeouts, then checks whether the application fails safely.

What changed from the OWASP Top 10 2021?

OWASP describes two new categories and one consolidation, and several entries changed rank:

• Software Supply Chain Failures (A03) expands the 2021 entry “Vulnerable and Outdated Components” to cover the whole chain, from dependencies to build pipelines.
• Mishandling of Exceptional Conditions (A10) is new and covers poor error handling and logic that fails open.
• Server-side request forgery, a standalone category in 2021, is now part of Broken Access Control.
• Security Misconfiguration rose from fifth to second, while Cryptographic Failures, Injection and Insecure Design each moved down.
• Two entries were renamed: “Identification and Authentication Failures” is now Authentication Failures, and “Logging and Monitoring” became Logging and Alerting, to stress that a log nobody reviews does not help.

How often is the OWASP Top 10 updated?

Roughly every three to four years. The 2025 edition is the eighth, after lists in 2003, 2004, 2007, 2010, 2013, 2017 and 2021. When a supplier’s test report or a customer’s contract cites “the OWASP Top 10”, check which year it means, because the categories and their numbering differ between editions.

What is the OWASP Top 10 used for?

Four things, mainly:

1. Developer training, as a short list of the mistakes that matter most.
2. Secure coding and code review, as a checklist for each release.
3. Supplier requirements, where a customer asks for evidence that an application has been tested against it.
4. Testing and reporting, as the floor for a web application penetration test, which covers OWASP penetration testing in detail. Testers map each finding to a category, so the report shows which risks were found and which were checked and found clear. Access control and insecure design need a tester logging in as each role, which scanners cannot do.

It also supports compliance. PCI DSS v4.0.1 Requirement 6.2.4 expects bespoke and custom software to be built with techniques that prevent common attacks, such as injection and access control flaws, and mapping your code review and testing to the OWASP Top 10 is a common way to show that. The list is deliberately short; for a full, testable specification, use the OWASP ASVS.

Is there an OWASP Top 10 for APIs, mobile and AI?

Yes, OWASP runs separate lists for other technologies. The OWASP API Security Top 10 (2023 edition) starts with broken object level authorisation, and it is what an API penetration test is measured against. Mobile apps have the OWASP Mobile Top 10, and applications built on large language models have their own OWASP Top 10 for LLM Applications, led by prompt injection. Our mobile app security testing checklist goes further for iOS and Android, covering the eight areas of the OWASP MASVS.

Why Sovereign Secure?

Sovereign Secure is a PCI SSC-approved QSA company and ISO 27001 certified. We test web applications, APIs, networks, cloud, mobile apps and AI systems by hand, and map every web finding to the OWASP Top 10 so your developers, auditors and customers read the same language.

To have an application tested against the current list, request a fixed-price penetration testing quote, or browse the rest of our cyber security glossary.