The OWASP Top 10 you are reading about right now is the 2025 edition, not 2021, and there is no separate "2024 edition" despite what a few outdated articles still claim. This guide covers:
What OWASP actually stands for and how the Top 10 gets built, methodology and all
A full history of the list, and exactly what changed between 2021 and 2025
Every one of the 10 categories, broken down with real CWE data, not just plain-language guesses
How the list connects to compliance frameworks and how bug bounty hunters actually use it
OWASP stands for the Open Worldwide Application Security Project, a nonprofit foundation that maintains this list as a free, community-driven standard. The OWASP Top 10 itself ranks the ten most critical security risks to web applications, based on real contributed data rather than opinion.
A few terms get used loosely in most explanations, but keeping them separate actually helps:
A vulnerability is the weakness itself, like an input field that never validates what gets typed into it.
A threat is the attacker or event that could exploit that weakness.
Risk is the combination of the two, how likely exploitation is, multiplied by how bad the impact would be if it happened.
A CWE, or Common Weakness Enumeration, is a standardized identifier for a specific type of software flaw. The OWASP Top 10 groups hundreds of individual CWEs into 10 broader risk categories.
The OWASP Top 10 is fundamentally a prioritized view of risk, built from CWE data. That makes it a strong starting point for learning what does a web application security researcher actually spends their time testing, but on its own it is not a complete security program.
How OWASP Actually Builds This List
Most articles describe the methodology in one vague sentence. The real process is more specific, and it matters for understanding why the rankings shifted so much this time:
The 2025 team analyzed 589 CWEs in total, a substantially larger dataset than the 2021 edition worked from.
Of those, 248 CWEs ultimately got mapped across the 10 final categories, up from 218 in 2021.
The data came from more than 500,000 applications across 40 or more contributing organizations, roughly double the data volume behind the 2021 edition.
A practitioner survey ran alongside the raw data to catch emerging risks that automated scans have not caught up to yet.
OWASP explicitly chose not to score this edition using CVSS v4.0, since that scoring algorithm changed too fundamentally to cleanly produce the separate Exploit and Impact sub-scores the ranking model depends on. They kept using CVSS v2 and v3 style scoring instead.
Any brand new category now needs real evidence to qualify. The new A10 category required at least 24 CWEs with documented real-world exploitation, a higher bar than the reasoning OWASP used to justify SSRF's addition back in 2021.
This level of rigor is worth knowing because it explains why the 2025 rankings moved more than any previous update, the underlying data genuinely grew, not just the interpretation of it. Anyone wanting the bigger picture beyond this one list can start with the career guide on how to get into bug bounty, which covers where this fits into a full roadmap.
A Brief History: OWASP Top 10 Through the Years
The list has an established, non-trendy release rhythm:
Editions released: 2003, 2004, 2007, 2010, 2013, 2017, 2021, and now 2025.
That works out to roughly every three to four years, driven by community data collection cycles rather than a fixed calendar.
The 2025 edition was announced at the OWASP Global AppSec Conference in Washington D.C. in November 2025, with the final version locked in January 2026.
Knowing this history matters for one practical reason: the OWASP Top 10 has over two decades of established practice behind it, not a framework that could disappear or get replaced next year.
What Changed From 2021 to 2025
Four structural shifts define this update:
SSRF (Server-Side Request Forgery) stopped being its own category and merged directly into Broken Access Control.
Security Misconfiguration jumped from #5 to #2, driven largely by cloud misconfigurations and weak default settings.
"Vulnerable and Outdated Components" got broadened and renamed to Software Supply Chain Failures, now covering the entire dependency and build pipeline, not just outdated libraries.
Mishandling of Exceptional Conditions entered as a completely new category at #10, covering poor error handling and fail-open logic.
Injection, Cryptographic Failures, and Insecure Design all slid down the ranking as a result, mostly because two new categories pushed everything else down a spot rather than those risks actually mattering less.
The OWASP Top 10:2025, Category by Category
1. Broken Access Control
The largest single category, with 40 mapped CWEs, more than any other entry on the list.
Happens when an application fails to enforce what a logged-in user can see or do.
Often as simple as changing an ID in a URL to view someone else's data.
Now absorbs SSRF too, covering cases where a server gets tricked into requesting internal resources it should never reach.
Bug bounty angle: hunters who systematically test IDs, roles, and parameters tend to find some of the highest-value bugs on any program.
2. Security Misconfiguration
Jumped from #5 to #2 in this edition.
Covers default credentials, exposed admin panels, overly permissive cloud storage, and unnecessary features left switched on.
The jump tracks closely with how much infrastructure has moved to the cloud, where one misconfigured setting can expose an entire dataset.
Bug bounty angle: often the fastest category to find real issues in during recon, since exposed storage buckets and default logins show up constantly.
3. Software Supply Chain Failures
A brand new category, expanded from the old "Vulnerable and Outdated Components" entry.
Covers vulnerabilities across the build pipeline, container images, and distribution infrastructure, not just outdated packages.
Named CWEs in this category include CWE-1035 (using components with known vulnerabilities), CWE-1104 (unmaintained third-party components), CWE-1329, and CWE-1357.
The shift means scanning a package-lock file for known CVEs no longer covers the full category.
Bug bounty angle: harder to test directly since much of it happens inside a company's build process, but checking dependency and library versions still belongs in a solid recon routine.
4. Cryptographic Failures
Dropped from #2 to #4, with 32 mapped CWEs.
Covers cleartext data transmission, weak or deprecated hashing algorithms, hardcoded secrets, and predictable tokens.
An average of 3.80 percent of tested applications carry at least one of these 32 CWEs.
The drop mostly reflects industry-wide improvement in TLS adoption, not that cryptographic issues stopped mattering.
Bug bounty angle: checking for plain HTTP on sensitive pages, weak session tokens, and exposed API keys in client-side code remains a reliable way to find valid, payable bugs.
5. Injection
Dropped from #3 to #5, with 38 mapped CWEs, more associated CVEs than almost any other category.
Covers SQL injection, cross site scripting, and any flaw where untrusted input gets executed as code instead of treated as plain data.
Spans a wide range: cross site scripting is high frequency but lower impact, while SQL injection is lower frequency but far higher impact.
Bug bounty angle: automated scanners catch a lot of the obvious cases, so manual testing on unusual input fields tends to find what scanners miss.
6. Insecure Design
Slid from #4 to #6 as the two new categories pushed it down.
Covers architecture and logic flaws rather than implementation bugs: weak password reset flows, missing threat modeling, or business logic that allows price manipulation.
OWASP notes real industry improvement here since 2021, tied to more threat modeling and secure design practices.
Bug bounty angle: this category rewards creative thinking over tool usage, since no scanner reliably catches a flawed business rule.
7. Authentication Failures
Kept its #7 position, with a slight rename from "Identification and Authentication Failures."
Covers weak password policies, missing multi factor authentication on sensitive actions, session fixation, and insecure credential storage.
Bug bounty angle: testing login flows, password reset processes, and session handling remains one of the more approachable categories for beginners.
8. Software or Data Integrity Failures
Covers missing integrity checks on software updates and unsafe deserialization of untrusted data.
Differs from Software Supply Chain Failures by focusing on whether integrity gets verified at all, not where components come from.
Shows up more often in API-heavy and enterprise targets than typical consumer web applications.
9. Security Logging and Alerting Failures
Covers missing or incomplete logs, logs nobody ever reviews, and logs that store sensitive data insecurely.
Harder to test as an outside hunter, since it shows up more in how a company responds after an incident than in a single report.
Worth flagging in a report when observed during testing, even without a direct proof of concept.
10. Mishandling of Exceptional Conditions
A completely new category, bundling 24 CWEs that needed documented real-world exploitation to qualify.
Covers how an application behaves under unexpected input, resource shortages, timeouts, or internal errors.
Named CWEs include CWE-209 (verbose stack traces leaking in HTTP responses), CWE-476 (NULL pointer dereferences), and CWE-636 (fail-open logic on authentication checks).
Half of OWASP's own survey respondents ranked this their top emerging concern, despite it barely showing up in scan data historically.
Bug bounty angle: triggering unusual inputs and reading error responses carefully is exactly how hunters find this one.
Why This List Matters Beyond Bug Bounty
The OWASP Top 10 is not just a bug bounty reference:
PCI DSS 4.0 references OWASP Top 10 coverage directly under Requirement 6.2.4.
SOC 2 secure development criteria and HIPAA's technical safeguards both treat OWASP Top 10 coverage as accepted evidence of secure coding practice.
None of this makes a company automatically compliant, but it means the same knowledge that helps a bug bounty hunter find a payable bug also matters directly for anyone aiming at an employed application security or penetration testing role. Web Application Security Testing Checklist turns these ten categories into an actual step by step testing workflow rather than a list to memorize.
How to Actually Practice Finding These Vulnerabilities
Reading the categories only goes so far. Real progress needs hands on practice:
PortSwigger's Web Security Academy lets beginners practice finding real examples of each category in a legal, built for testing environment, completely free.
OWASP Juice Shop is a deliberately vulnerable practice application maintained by OWASP itself, and it remains one of the most widely used training tools for exactly this list.
A proxy tool is non-negotiable for this kind of testing. Burp Suite Tutorial for Beginners walks through setting one up from scratch.
Conclusion
The OWASP Top 10:2025 reshuffled more than any previous update, but the underlying skill it demands has not changed. Understanding these categories well enough to recognize them in a real application, backed by actual CWE data rather than guesswork, is what separates a beginner from someone who gets paid consistently. That same foundation is exactly what bug bounty hunting builds on from the very start.
Skill Shikshya's bug bounty training course builds that skill directly, working through every category on this list with live labs and real targets.
Frequently Asked Questions
About Author:
Meet Mr. Anish Bhattarai, Cybersecurity mentor at SkillShikshya. He guides learners through security fundamentals, ethical hacking practices, and hands-on cybersecurity techniques to turn technical curiosity into practical security skills.