The OWASP Top 10 is the best-known list of the most critical security risks in web applications. The latest edition, the OWASP Top 10 2025, reshuffles the ranking and adds two new categories: software supply chain failures and mishandling of exceptional conditions. This guide explains each risk in plain language, with a simple example and the main defenses, so you know exactly what to learn first.
What Is OWASP?
OWASP, the Open Worldwide Application Security Project, is a nonprofit foundation that publishes free, community-driven security resources such as the Testing Guide, ASVS and Cheat Sheet Series. The Top 10 is its flagship awareness document. It is built from real vulnerability data contributed by companies and security teams, plus a community survey, and is updated every few years. The 2025 edition is the eighth version and the first major update since 2021.
OWASP Top 10 2025 at a Glance
| Rank | Category | Change vs 2021 |
|---|---|---|
| A01 | Broken Access Control | Still #1, now includes SSRF |
| A02 | Security Misconfiguration | Up from #5 |
| A03 | Software Supply Chain Failures | New (expands “Vulnerable and Outdated Components”) |
| A04 | Cryptographic Failures | Down from #2 |
| A05 | Injection | Down from #3 |
| A06 | Insecure Design | Down from #4 |
| A07 | Authentication Failures | Same position |
| A08 | Software or Data Integrity Failures | Same position |
| A09 | Security Logging and Alerting Failures | Renamed (“Monitoring” became “Alerting”) |
| A10 | Mishandling of Exceptional Conditions | New |
The 10 Risks Explained
A01: Broken Access Control
The application lets users do things outside their permissions: reading other users’ data, calling admin functions or abusing the server to reach internal systems (SSRF, which is now part of this category).
Example: Changing /api/orders/1001 to /api/orders/1002 returns another customer’s order (an IDOR).
How to prevent it: Deny by default, enforce authorization checks on the server for every object and function, and never trust IDs sent by the client.
A02: Security Misconfiguration
Insecure defaults and sloppy setup: default credentials, open cloud storage buckets, verbose error pages, unnecessary features or missing security headers.
Example: A public S3 bucket exposes database backups, or a debug page leaks stack traces.
How to prevent it: Use hardened, repeatable configurations, remove unused features, and scan configurations automatically in your CI/CD pipeline.
A03: Software Supply Chain Failures
Risks that come from everything your software depends on: third-party libraries, build systems, CI/CD pipelines and update mechanisms. This replaces and widens the old “Vulnerable and Outdated Components” category.
Example: A compromised npm package or a poisoned build step ships malicious code to all your users.
How to prevent it: Keep an inventory (SBOM), pin and verify dependencies, patch quickly, and protect your build pipeline like production.
A04: Cryptographic Failures
Sensitive data is not properly protected because encryption is missing, weak or badly implemented, or keys are poorly managed.
Example: Passwords stored with MD5, or a login form served over plain HTTP.
How to prevent it: Use TLS everywhere, strong modern algorithms, salted slow hashes like bcrypt or Argon2 for passwords, and proper key management.
A05: Injection
Untrusted input is interpreted as code or a query. This includes SQL and NoSQL injection, OS command injection and cross-site scripting (XSS).
Example: A login form where ' OR 1=1-- bypasses authentication.
How to prevent it: Use parameterized queries, validate input, encode output for its context and apply a Content Security Policy. Our SQLmap guide shows how testers confirm SQL injection in authorized assessments.
A06: Insecure Design
The flaw is in the design itself, not the code. No amount of perfect implementation fixes a missing security control.
Example: A password reset flow that relies on easy-to-guess security questions.
How to prevent it: Threat-model features early, use secure design patterns and write abuse cases alongside user stories.
A07: Authentication Failures
Weaknesses in login, session and token handling that let attackers take over accounts.
Example: No rate limiting allows credential stuffing, or session tokens remain valid after logout.
How to prevent it: Enforce MFA, rate-limit logins, check passwords against breached lists and manage sessions securely on the server side.
A08: Software or Data Integrity Failures
The application trusts code or data without verifying its integrity.
Example: Unsigned auto-updates, or insecure deserialization of user-controlled objects.
How to prevent it: Sign and verify updates and artifacts, and avoid deserializing untrusted data.
A09: Security Logging and Alerting Failures
Events are not logged, or they are logged but nobody is alerted, so attacks go unnoticed. The rename to “Alerting” stresses that logs without response are not enough.
Example: Thousands of failed logins happen overnight with no alert.
How to prevent it: Log security-relevant events, centralize them in a SIEM, create alerts for suspicious patterns and test your response process.
A10: Mishandling of Exceptional Conditions
New in 2025. The application handles errors and unusual situations badly: it fails open, leaks details or ends up in an inconsistent state.
Example: An authorization service times out and the application grants access by default.
How to prevent it: Fail closed, handle every error path explicitly, return generic error messages and test how the app behaves under failure.
How to Use the OWASP Top 10
- Developers: treat it as a minimum checklist during design and code review, then go deeper with the OWASP ASVS and Cheat Sheet Series.
- Pentesters and bug bounty hunters: use it to structure web testing; tools like Burp Suite help you test access control, injection and authentication in practice.
- SOC and blue teams: map detections to the categories, especially access control abuse, injection attempts and authentication attacks.
- Beginners: practice each category in legal labs and CTFs. See our first CTF methodology and the cybersecurity career roadmap.
Common Misconceptions
- “It is a complete security standard.” It is an awareness document. For verification requirements, use OWASP ASVS.
- “Fixing the Top 10 makes an app secure.” It covers the most common risks, not every risk.
- “The ranking is about severity.” Ranking reflects data on prevalence and impact, so a lower-ranked issue can still be critical in your app.
Frequently Asked Questions
What is the latest version of the OWASP Top 10?
The latest edition is the OWASP Top 10 2025, which replaced the 2021 list.
What is number one in the OWASP Top 10?
Broken Access Control is A01, as it was in 2021, and it now also includes server-side request forgery (SSRF).
What are the new categories in 2025?
Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10).
Is the OWASP Top 10 only for web applications?
This list targets web applications. OWASP publishes separate lists for APIs, mobile apps and LLM applications.
Conclusion
The OWASP Top 10 2025 is the best starting map for web security. Learn what each category means, practice finding it in labs, and use the defenses above in your own code. For more hands-on content, browse our Web Security articles.