OWASP Top 10 (2025): All 10 Vulnerabilities Explained, With Examples

## What Is the OWASP Top 10? The OWASP Top 10 is a standard awareness document that lists the ten most critical security risks to web applications. It is published by the [Open Worldwide Application Security Project (OWASP)](https://owasp.org/Top10/2025/), a non-profit foundation, and is built from vulnerability data contributed by security firms plus a survey of practitioners. **In short:** it is the list developers, testers and auditors use as a shared starting point for "what usually goes wrong" in web apps. A few things it is *not*: - **Not a compliance standard.** No law requires "OWASP compliance". However, standards such as PCI DSS and many client security questionnaires reference it, so it is often used as evidence of secure development. - **Not a complete checklist.** It covers the most common risk categories, not every weakness. For a full testing standard, use the [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) or the OWASP Web Security Testing Guide. ## The OWASP Top 10:2025 List The current edition is **OWASP Top 10:2025**, the eighth installment. It replaced the 2021 list. | Rank | Category | |---|---| | A01:2025 | Broken Access Control | | A02:2025 | Security Misconfiguration | | A03:2025 | Software Supply Chain Failures | | A04:2025 | Cryptographic Failures | | A05:2025 | Injection | | A06:2025 | Insecure Design | | A07:2025 | Authentication Failures | | A08:2025 | Software or Data Integrity Failures | | A09:2025 | Security Logging and Alerting Failures | | A10:2025 | Mishandling of Exceptional Conditions | ## What Changed From the 2021 List? There are two new categories and one consolidation: | 2021 | 2025 | Change | |---|---|---| | A01 Broken Access Control | A01 Broken Access Control | Still #1. SSRF (A10:2021) merged into it | | A05 Security Misconfiguration | A02 Security Misconfiguration | Up from #5 | | A06 Vulnerable and Outdated Components | A03 Software Supply Chain Failures | Expanded to the whole build and delivery chain | | A02 Cryptographic Failures | A04 Cryptographic Failures | Down two places | | A03 Injection | A05 Injection | Down two places | | A04 Insecure Design | A06 Insecure Design | Down two places | | A07 Identification and Authentication Failures | A07 Authentication Failures | Renamed | | A08 Software and Data Integrity Failures | A08 Software or Data Integrity Failures | Same position | | A09 Security Logging and Monitoring Failures | A09 Security Logging and Alerting Failures | Renamed to stress alerting | | A10 Server-Side Request Forgery | A10 Mishandling of Exceptional Conditions | New category; SSRF moved into A01 | If your security policy, pentest scope or developer training still refers to the 2021 list, it is worth updating the references. ## The 10 Risks Explained ### A01:2025 Broken Access Control Users can do things outside their intended permissions. OWASP's data found some form of broken access control in every application tested, which is why it stays at #1. **Examples:** - Changing `/api/invoices/1042` to `/api/invoices/1043` and seeing another customer's invoice (insecure direct object reference). - A regular user reaching admin endpoints because the check only exists in the front end. - Server-side request forgery (SSRF): the app fetches a URL supplied by the user and can be pointed at internal services. **Prevention:** deny by default, enforce authorisation on the server for every request and every object, log access-control failures, and validate and allow-list any URL your server fetches. ### A02:2025 Security Misconfiguration Insecure defaults, incomplete setup or unnecessary features. It moved up because more application behaviour now lives in configuration — cloud settings, containers, frameworks. **Examples:** public cloud storage buckets, default admin credentials, debug mode left on in production, permissive CORS, missing security headers. **Prevention:** a repeatable hardening process for every environment, minimal installs, configuration kept in code and reviewed, and automated checks for drift. ### A03:2025 Software Supply Chain Failures Compromises anywhere in how your software is built, sourced and delivered — not just outdated libraries. **Examples:** an npm or PyPI package with a known critical vulnerability, a malicious package with a name close to a popular one, a compromised CI/CD pipeline or build plugin. **Prevention:** keep an inventory of dependencies (an SBOM), monitor advisories, pin and verify versions, restrict who can change build pipelines, and remove unused packages. ### A04:2025 Cryptographic Failures Weak or missing protection of data in transit and at rest. **Examples:** passwords stored with MD5 or SHA-1, sensitive data sent over plain HTTP, hard-coded keys in source code, weak random numbers used for tokens. **Prevention:** TLS everywhere, modern password hashing (Argon2, bcrypt or scrypt), keys in a secrets manager, and do not store sensitive data you don't need. ### A05:2025 Injection Untrusted input is interpreted as a command or query. This includes SQL, NoSQL, OS command and LDAP injection, and cross-site scripting (XSS). **Example:** `SELECT * FROM users WHERE username = '' OR '1'='1'` — a classic SQL injection that returns every user. **Prevention:** parameterised queries or a safe ORM, context-aware output encoding, server-side input validation, and never concatenating user input into queries or shell commands. ### A06:2025 Insecure Design Flaws in the design itself, which perfect code cannot fix. **Examples:** a password reset that relies on guessable security questions, no limit on how many gift cards one account can redeem, business logic that trusts the client's price. **Prevention:** threat modelling during design, secure design patterns, abuse-case testing, and limits on sensitive business actions. ### A07:2025 Authentication Failures Weaknesses in confirming who a user is and managing their session. **Examples:** no protection against credential stuffing, weak passwords allowed, session tokens that never expire or are exposed in URLs. **Prevention:** multi-factor authentication, checks against breached passwords, rate limiting and lockout, and secure session handling with expiry after logout. ### A08:2025 Software or Data Integrity Failures Code or data is trusted without checking it hasn't been tampered with. **Examples:** auto-updates installed without signature checks, insecure deserialisation of user-controlled objects, scripts loaded from a CDN without integrity checks. **Prevention:** digital signatures and checksums, Subresource Integrity for third-party scripts, and never deserialising untrusted data without validation. ### A09:2025 Security Logging and Alerting Failures Attacks go unnoticed because events aren't logged, or no one is alerted when they are. **Examples:** failed logins not recorded, logs only stored on the server an attacker controls, alerts that nobody reviews. **Prevention:** log authentication, access-control and input-validation failures with enough context, protect logs from tampering, and route high-value events to alerts someone acts on. ### A10:2025 Mishandling of Exceptional Conditions A new category covering what happens when things go wrong: poor error handling, logic errors and "failing open". **Examples:** stack traces or database errors shown to users, a payment check that approves the transaction when the payment service times out, crashes when a parameter is missing. **Prevention:** handle errors where they occur, fail securely (deny when in doubt), show generic error messages to users while logging the detail, and test unusual inputs and states. ## OWASP Top 10 vs. OWASP API Security Top 10 OWASP publishes separate lists for other technologies. If your product is mostly APIs — common for fintech and mobile apps — also review the **OWASP API Security Top 10 (2023)**, where broken object-level authorisation (API1:2023) is ranked first. See our [API security best practices guide](/blog/api-security-best-practices-2025). There is also an OWASP Mobile Top 10 for mobile apps. ## How to Test Your Application Against the OWASP Top 10 1. **Map your app.** List every user role, endpoint and third-party dependency. 2. **Use automated tools for the basics.** Dependency scanners (A03) and configuration checks (A02) catch a lot cheaply. 3. **Test manually for logic and access control.** Scanners rarely find A01, A06 or A10 issues, because they depend on how your business rules work. This is where a manual [web application penetration test](/penetration-testing) adds the most value. 4. **Fix, then retest.** Confirm each finding is actually resolved, and keep the evidence for auditors and clients. 5. **Repeat after major releases.** The risks change as your code and infrastructure change — see our guide to the [vulnerability management lifecycle](/blog/vulnerability-management-lifecycle). ## Frequently Asked Questions ### What is the latest version of the OWASP Top 10? The latest version is the OWASP Top 10:2025. The previous edition was published in 2021. ### How often is the OWASP Top 10 updated? Roughly every three to four years. Recent editions were 2013, 2017, 2021 and 2025. ### Is the OWASP Top 10 a compliance standard? No. It is an awareness document. Standards such as PCI DSS reference it, and clients often ask about it, but there is no official "OWASP certification" for an application. ### Is CSRF in the OWASP Top 10? CSRF does not have its own category. In the 2025 list it is included under A01 Broken Access Control. ### Where did SSRF go in 2025? Server-side request forgery, A10 in 2021, is now part of A01:2025 Broken Access Control. ### How do I learn the OWASP Top 10? Read the official pages at owasp.org, practise on deliberately vulnerable training apps such as OWASP Juice Shop, and learn to test manually. ## Next Steps Knowing the list is the start; finding these issues in your own app is the hard part. Most of the high-impact findings in our tests fall under A01 (access control) and A06 (design flaws) — the issues automated scanners usually miss. **Want to know where your app stands?** [Book a web application penetration test](/penetration-testing) with Hackrowd Technology, or start with a [free exposure snapshot](/exposure-snapshot) of your publicly visible footprint.