OWASP Top Ten

The 2025 list

The most current release is the OWASP Top 10:2025. Its categories, in order, are:

1. A01 Broken Access Control: users acting outside their permissions, such as viewing another user's data by changing an ID in a URL.
2. A02 Security Misconfiguration: default settings, verbose errors, open cloud storage, unnecessary features left enabled.
3. A03 Software Supply Chain Failures: risks from dependencies, build systems and distribution, a new and broader category in this edition.
4. A04 Cryptographic Failures: weak or missing encryption, poor key handling, sensitive data in plain text.
5. A05 Injection: SQL, command and other injection, including cross-site scripting.
6. A06 Insecure Design: flaws in the design itself that no amount of careful coding will fix.
7. A07 Authentication Failures: weak login, session and credential handling.
8. A08 Software or Data Integrity Failures: trusting updates, plugins or serialized data without verifying them.
9. A09 Security Logging and Alerting Failures: attacks that go unnoticed because nothing records or flags them.
10. A10 Mishandling of Exceptional Conditions: a new category about errors and edge cases that leave systems in unsafe states.

If you learned from the 2021 list, note the changes: supply chain risk now has its own high-ranked category, server-side request forgery no longer stands alone, and exception handling is new.

Why every developer needs it, not just security people

Most vulnerabilities are introduced by ordinary developers doing ordinary work: a query built by string concatenation, an access check done only in the front end, a dependency nobody updated, a token written to a log. These are routine mistakes, not exotic attacks. Knowing the ten categories is enough to catch most of them in your own code and in review.

The one that catches the most people

Broken access control has been at the top for good reason. Almost everyone gets login right and then checks authorisation in the wrong place, or forgets it on one endpoint out of forty. Every API endpoint should check, on the server, that this user may do this action on this object.

How to use it well

• Read the page for each category, including its prevention section and example attack scenarios.
• Go through one of your own projects category by category and write down what you find.
• Pair it with the OWASP Cheat Sheet Series, which gives concrete implementation guidance (for example on authentication, session management and input validation).
• Practise on a deliberately vulnerable app such as OWASP Juice Shop to see these flaws from the attacker's side.

Limits to keep in mind

It is an awareness document, not a complete standard. It tells you what to worry about, not everything to check. For a thorough checklist, OWASP's Application Security Verification Standard (ASVS) goes much further. For mobile apps, use OWASP's mobile project instead.

Common questions

How long does it take to read? An afternoon for the whole list; longer if you follow the linked guidance, which is worth it.

Is it asked about in jobs? Backend and full-stack roles often expect familiarity with it, and it is a common topic in secure coding training.

Best for: every developer who writes code that faces the internet, and students who want a solid security baseline before their first job.