OWASP Top 10 (2025) Explained with Real Examples
The OWASP Top 10 is the best-known reference for web application security. Developers use it to learn what to avoid, security teams use it to structure testing, and auditors and customers use it as shorthand for “has this application been built and tested properly?” The latest edition, the OWASP Top 10:2025, reorganizes the list around root causes and adds two new categories that reflect how modern applications are actually attacked.
This guide explains each of the ten categories in plain language, with real-world examples, how to prevent each risk and how penetration testers look for it.
What Is the OWASP Top 10?
The OWASP Top 10 is published by the Open Worldwide Application Security Project (OWASP), a non-profit foundation. OWASP describes it as a standard awareness document representing a broad consensus about the most critical security risks to web applications. It is built from vulnerability data contributed by organizations and testing providers, combined with a community survey for risks that are hard to measure in testing data.
Two points are often misunderstood:
- It is an awareness document, not a complete standard. For verifiable security requirements, OWASP recommends the Application Security Verification Standard (ASVS).
- Each entry is a category, not a single vulnerability. Each groups many related weaknesses (CWEs); in the 2025 edition the categories contain on average about 25 CWEs each.
What Changed in the OWASP Top 10:2025
2025 | Category | Change from 2021 |
|---|---|---|
A01 | Broken Access Control | Still #1; now also includes Server-Side Request Forgery (SSRF), which was a separate category in 2021 |
A02 | Security Misconfiguration | Up from #5 |
A03 | Software Supply Chain Failures | New name and wider scope; expands the former “Vulnerable and Outdated Components” to dependencies, build systems and distribution |
A04 | Cryptographic Failures | Down from #2 |
A05 | Injection | Down from #3 |
A06 | Insecure Design | Down from #4 |
A07 | Authentication Failures | Same position; renamed from “Identification and Authentication Failures” |
A08 | Software or Data Integrity Failures | Same position |
A09 | Security Logging and Alerting Failures | Same position; renamed from “Monitoring” to “Alerting”, because logging without alerting has little value |
A10 | Mishandling of Exceptional Conditions | New category |
A01:2025 Broken Access Control
What it is: The application does not properly enforce what a user is allowed to see or do. Users can access other users’ data, perform administrative actions or reach functions they should not.
Common forms: insecure direct object references (IDOR), where changing an ID in a request returns someone else’s record; missing authorization checks on API endpoints; privilege escalation from a normal user to an administrator; and, since 2025, server-side request forgery (SSRF), where an attacker makes the server send requests to internal systems.
Real-world example: In 2019, the US title insurance company First American Financial was reported to have exposed hundreds of millions of documents containing sensitive personal and financial data. Documents were accessible through a link whose identifier could simply be incremented to view other customers’ records, with no access check. It is a textbook IDOR.
How to prevent it: deny access by default; enforce authorization on the server for every request, ideally through a central mechanism; check object ownership, not just authentication; and validate and restrict outbound requests the server makes on behalf of users.
How testers find it: with two accounts per role, testers replay each request from one user with another user’s session and identifiers. Scanners rarely find these issues, which is why broken access control is one of the most valuable findings in a manual web application penetration test.
A02:2025 Security Misconfiguration
What it is: Insecure settings anywhere in the stack: the application, framework, web server, database, cloud services or containers.
Common forms: default credentials, unnecessary features or sample applications left enabled, detailed error messages in production, missing security headers, overly permissive cloud storage or CORS policies, and debug or administration interfaces exposed to the internet.
Real-world example: Publicly accessible cloud storage buckets and databases left open without authentication have been behind a long series of large data exposures. In many of these cases no attack technique was needed at all: the data was simply available to anyone who found it.
How to prevent it: use hardened, repeatable configuration managed as code; remove what is not needed; separate environments; and check configuration automatically against benchmarks, such as the CIS Benchmarks for cloud and server platforms.
A03:2025 Software Supply Chain Failures
What it is: Compromise or weakness anywhere in the chain that produces your software: third-party libraries, build systems, CI/CD pipelines, package registries and distribution. It expands the former “Vulnerable and Outdated Components” category.
Real-world examples:
- SolarWinds (2020): attackers compromised the build process of a widely used IT management product and inserted malicious code into legitimate, signed updates delivered to thousands of customers.
- Log4Shell (2021): a critical remote code execution vulnerability in the Log4j logging library affected a vast number of applications, many of which did not know they depended on it.
- xz Utils (2024): a backdoor was deliberately introduced into a widely used open-source compression library by a contributor who had built trust over a long period, and was discovered shortly before it reached many stable Linux distributions.
Our own analysis of the supply chain attack on Trivy, KICS and LiteLLM shows that even security tools are targets.
How to prevent it: maintain a software bill of materials (SBOM); monitor dependencies for known vulnerabilities; pin and verify versions; protect build pipelines and their secrets; and sign and verify build artifacts. See our Software Supply Chain Penetration Testing service.
A04:2025 Cryptographic Failures
What it is: Sensitive data is not adequately protected in transit or at rest, or cryptography is used incorrectly.
Common forms: sensitive data sent without TLS; weak or outdated algorithms and protocols; passwords stored with fast, unsalted hashes instead of a dedicated password hashing function; hardcoded or poorly managed keys; and predictable random values used for tokens.
Real-world example: In 2012, LinkedIn suffered a breach in which user passwords had been stored as unsalted SHA-1 hashes. Because these hashes are fast to compute and identical passwords produce identical hashes, a large share of them could be cracked, and the full scale of the breach became clear years later when a much larger dataset appeared for sale.
How to prevent it: classify the data you handle and encrypt sensitive data in transit and at rest; use TLS everywhere; store passwords with a slow, salted algorithm designed for the purpose, such as Argon2, scrypt or bcrypt; manage keys in a dedicated secrets or key management service; and never invent your own cryptography.
A05:2025 Injection
What it is: Untrusted input is interpreted as code or as part of a command or query. Injection includes SQL injection, OS command injection, LDAP injection, template injection and cross-site scripting (XSS).
Real-world example: In 2023, a SQL injection vulnerability in the MOVEit Transfer file transfer product (CVE-2023-34362) was exploited at large scale by the Cl0p ransomware group to steal data from a very large number of organizations, many of them through their suppliers.
Our research blog includes two detailed injection case studies: the wp2shell analysis, where a SQL injection in WordPress core became part of a chain leading to remote code execution, and the GitLab GraphQL vulnerability, a code injection reachable through the GraphQL layer.
How to prevent it: use parameterized queries or safe ORM methods; avoid passing user input to interpreters and system commands; use context-aware output encoding and a Content Security Policy against XSS; and validate input against an allowlist where possible.
A06:2025 Insecure Design
What it is: Flaws in the design and business logic of the application itself, rather than bugs in its implementation. A perfectly implemented feature can still be insecure if it was designed without considering how it could be abused.
Common forms: password reset or account recovery flows that can be abused to take over accounts; discount and refund logic that can be manipulated; workflows that let users skip steps such as payment or approval; and missing limits that allow mass enumeration or automated abuse.
Example: An online store applies a discount code on the server but never checks whether it has already been used in the same order. By submitting the code repeatedly, a user reduces the price to zero. Every line of code works as written; the design is what is broken.
How to prevent it: use threat modeling during design; define abuse cases alongside use cases; apply secure design patterns and established reference architectures; and include business logic scenarios in security testing. Our Secure Software Development Training covers threat modeling in practice.
A07:2025 Authentication Failures
What it is: Weaknesses that let attackers impersonate users or take over accounts.
Common forms: no protection against credential stuffing or brute force; weak password rules; missing or bypassable multi-factor authentication; session identifiers that do not change after login or never expire; and flaws in “remember me”, password reset and token handling, including JWT validation mistakes.
Real-world example: In 2023, the genetic testing company 23andMe disclosed that attackers had used credential stuffing, logging in with usernames and passwords leaked from other services, to access a set of customer accounts. Through a feature that shared information between related users, the exposure extended to data about millions of additional people.
How to prevent it: offer and encourage multi-factor authentication; rate-limit and monitor login attempts; check passwords against known breached passwords; use secure, well-tested session and token management; and rotate session identifiers after login.
A08:2025 Software or Data Integrity Failures
What it is: The application trusts code or data without verifying its integrity. Where A03 covers the wider supply chain, A08 focuses on lower-level trust boundaries inside the application and its update and deployment processes.
Common forms: insecure deserialization of untrusted data; auto-update mechanisms that do not verify signatures; loading scripts or plugins from untrusted locations; and CI/CD pipelines that deploy artifacts without verifying where they came from.
Example: An application stores a serialized object in a cookie and deserializes it on each request. An attacker modifies the cookie to contain a crafted object that executes code when deserialized on the server.
How to prevent it: never deserialize untrusted data with native serialization formats; prefer simple formats such as JSON with strict schemas; verify digital signatures on updates and artifacts; use Subresource Integrity for third-party scripts; and protect deployment pipelines.
A09:2025 Security Logging and Alerting Failures
What it is: Attacks are not detected because important events are not logged, logs are not monitored, or nobody is alerted when something suspicious happens. OWASP renamed the category in 2025 to emphasize alerting: logs that nobody acts on have little value.
Example: Many major breaches have been discovered months after the initial intrusion, often by a third party rather than the victim. The logs frequently contained the evidence all along; nobody was alerted to it.
How to prevent it: log authentication events, access control failures, input validation failures and administrative actions with enough context; protect logs from tampering; send them to a central system; and define alerts and response procedures for high-risk events. Our purple team guide explains how to test whether alerts actually fire.
A10:2025 Mishandling of Exceptional Conditions
What it is: A new category in 2025, covering how applications behave when something unexpected happens: errors, timeouts, unusual inputs, missing resources or partial failures.
Common forms: failing open, where a security check is skipped when an error occurs; verbose error messages that leak stack traces, queries or internal paths; inconsistent state after a partially failed transaction; and crashes or resource exhaustion triggered by malformed input.
Example: An authorization service times out under load, and the application’s error handler treats the failed check as a pass, granting access instead of denying it.
How to prevent it: fail closed by default; handle errors centrally and consistently; return generic error messages to users while logging details internally; use transactions so that failures roll back cleanly; and include malformed input and failure scenarios, such as fuzzing, in testing.
How to Use the OWASP Top 10 in Practice
- For developers: treat the list as a learning map. Each category links to prevention guidance and related CWEs. Secure coding training built around these categories pays off quickly; see our Secure Software Development Training.
- For security testing: use the Top 10 as a minimum checklist, not the full scope. A web application penetration test should cover every category, plus business logic specific to your application.
- For automated tools: SAST, DAST and software composition analysis catch parts of several categories, especially injection, misconfiguration and vulnerable components. They are weak at access control, insecure design and business logic, which need manual testing. Our guide to shift left security explains how to combine them.
- For requirements and audits: if you need a standard to build or verify against, use OWASP ASVS. “Compliant with the OWASP Top 10” is not a meaningful claim on its own, because the Top 10 is an awareness document.
- For APIs and AI features: use the OWASP API Security Top 10 and the OWASP Top 10 for LLM Applications alongside this list.
Frequently asked questions
Conclusion
The OWASP Top 10:2025 reflects how web applications are actually attacked today: access control is still the most common weakness, misconfiguration and supply chain risks have moved up, and error handling has become a category of its own. Use it to guide developer training, shape your testing and prioritize fixes, but treat it as a starting point rather than a finish line.
Want to know how your application holds up against the OWASP Top 10 and beyond? Explore our Web Application Penetration Testing service, or train your team with our Web Application Penetration Testing Training. Talk to our team to get started.
Subscribe to our cyber security newsletter