I remember the first time someone handed me the OWASP Top 10 and said “learn this.” I stared at it blankly. It read like a legal document written by people who hate beginners.

So here’s my version. Plain English, real examples, no fluff.

First — what even is OWASP?

OWASP is a non-profit that does one thing really well — tells the world what’s actually breaking in web applications. Not theory. Real data from real applications getting tested by real security teams.

Every few years they release the Top 10 — a list of the most dangerous vulnerability categories found across hundreds of thousands of apps. The 2025 edition just dropped, and it’s the biggest shake-up since 2021. Two brand new categories, one category got absorbed into another, and the overall philosophy shifted from “here are specific bugs” to “here are systemic failures in how software gets built.”

That last part matters. Let me explain as we go through the list.

What’s new in 2025?

Before the breakdown — here’s the quick version of what changed from 2021:

Security Misconfiguration jumped from #5 to #2. Supply chain attacks got their own dedicated category. SSRF (Server-Side Request Forgery) got merged into Broken Access Control. And a completely new category called “Mishandling of Exceptional Conditions” entered at #10.

The data behind this came from over 175,000 CVE records and 589 different weakness types. That’s not a guess — that’s evidence.

Now the list.

A01 — Broken Access Control

Still #1. Has been for two editions now.

The idea is simple: your application isn’t properly checking who is allowed to do what. A regular user can access admin pages. A customer can view another customer’s order by changing a number in the URL. An API returns data it shouldn’t because the developer forgot to check permissions on that endpoint.

This is why it stays at the top — it’s not a exotic vulnerability that requires skill to find. Change /profile/100 to /profile/101 and see whose data comes back. That’s it. That’s the test.

SSRF got folded into this category in 2025, which makes sense. Server-Side Request Forgery is fundamentally an access control problem — the server is being tricked into making requests to internal systems it shouldn’t touch.

A02 — Security Misconfiguration

Jumped from #5 to #2, and honestly this surprises nobody who does pentesting for a living.

Every single application tested showed some form of misconfiguration. Not most — every one. Default credentials still sitting on admin panels. S3 buckets wide open to the internet. Error messages spitting out full stack traces with file paths and framework versions. Security headers completely missing.

The thing about misconfigs is they’re embarrassing to find. You don’t need to write an exploit. You just look. And look. And look again. There’s always something.

A03 — Software Supply Chain Failures ⭐ New

This is the one I find most interesting, and also the most underestimated by beginners.

Modern applications don’t just run your code — they run hundreds of third-party libraries, packages, and tools. When any of those get compromised, your application is compromised too, even if your own code is perfect.

The 2021 version of this category was called “Vulnerable and Outdated Components” — basically “did you forget to update your npm packages?” The 2025 version is much bigger. It covers the entire supply chain: the code you pull in, the tools used to build your software, the CI/CD pipeline that deploys it, the package registries you trust.

Remember XZ Utils in 2024? A contributor spent two years building trust in an open-source project before injecting a backdoor into a compression library used across Linux systems worldwide. That’s a supply chain attack. Nobody’s login page caused that breach.

The supply chain is now the perimeter. Act accordingly.

A04 — Cryptographic Failures

Dropped from #2 to #4, but don’t let the ranking fool you — this one still causes catastrophic breaches.

Passwords stored in plain text. Sensitive data going over HTTP. JWT tokens with the algorithm set to none. MD5 hashes being used for anything security-related in 2025. These aren’t edge cases — they show up constantly.

The root cause is usually one of two things: developers not understanding cryptography well enough, or developers understanding it but taking shortcuts. Neither ends well.

A05 — Injection

Dropped from #3 to #5. Some people see this as injection becoming less dangerous. It isn’t — modern frameworks have just gotten better at preventing the most obvious forms of it.

SQL injection is 25+ years old and still shows up in production applications. Type a single quote into a search box. Watch for errors. That’s still a valid first move in 2025.

Beyond SQL — command injection, LDAP injection, template injection. The pattern is always the same: user input gets passed to an interpreter without being properly sanitized, and the interpreter runs it as a command instead of data.

A06 — Insecure Design

This one is harder to grasp at first because it’s not about a specific bug — it’s about the decisions made before a single line of code was written.

A password reset that sends a link with no expiry. A payment flow with no fraud checks. An API with no rate limiting because “we’ll add it later.” These aren’t coding mistakes. The code does exactly what it was designed to do. The design itself is wrong.

The distinction matters because you can’t patch insecure design the same way you patch a SQL injection. It requires rethinking the feature entirely.

A07 — Identification and Authentication Failures

Pretty straightforward — the application can’t reliably verify that you are who you claim to be.

Weak passwords being accepted. No limit on login attempts so attackers can brute force endlessly. Session tokens that survive after logout. No two-factor authentication on accounts that control sensitive data.

A lot of account takeovers trace back here. Not sophisticated attacks — just automated tools hammering login endpoints with leaked credential lists. Credential stuffing is depressingly effective because people reuse passwords everywhere.

A08 — Software and Data Integrity Failures

When an application trusts data or code without verifying it hasn’t been tampered with.

Auto-update systems that download and run code without checking a signature. CI/CD pipelines that run scripts pulled from external sources without verification. Insecure deserialization where attacker-controlled data gets unpacked and executed.

The SolarWinds attack is the textbook example here — attackers compromised the build system, so legitimate software updates contained malware. The update was signed correctly. The signature was valid. The code was malicious.

A09 — Security Logging and Alerting Failures

Nobody talks about this one enough.

An attack that goes undetected for six months is infinitely worse than an attack that triggers an alert in six minutes. Logging isn’t glamorous but it’s the difference between catching a breach while it’s happening versus discovering it when a journalist calls.

Failed login attempts not being recorded. No alerts on impossible travel (someone logging in from London then Tokyo twenty minutes later). Sensitive data appearing in logs in plain text. These are all logging failures, and they all make incident response harder than it needs to be.

A10 — Mishandling of Exceptional Conditions ⭐ New

Brand new for 2025, and honestly long overdue as its own category.

What happens when your application encounters something unexpected — a null value, a timeout, a malformed request, a database that’s down? If it crashes and dumps a stack trace, an attacker now knows your framework, your file structure, and your library versions. If it “fails open” — meaning it grants access when it can’t verify anything — that’s a security hole disguised as a convenience.

50% of OWASP survey respondents ranked this as their #1 emerging concern. The category covers 24 different weakness types that were previously scattered around under “poor code quality.” They finally got a home.

The principle is simple: applications should fail safely, quietly, and predictably.

Where to go from here

If you’re just starting out in security, this list is your curriculum. Pick one category, actually understand it — not just the definition, but how it gets exploited and how it gets fixed. Then move to the next.

HackTheBox and TryHackMe both have labs built around OWASP vulnerabilities. Do those. Read writeups from other people after you’ve attempted challenges yourself. See how they think.

The OWASP Top 10 isn’t perfect — it’s a data-driven snapshot of what’s common, not a complete map of everything dangerous. But for beginners it’s as good a starting point as any.

Just don’t make the mistake of treating it as a checklist to tick off. Treat it as a way to understand how web applications fail. That understanding is what separates a good pentester from someone running automated scanners and calling it a day.