OWASP Top 10 2025: Every Risk Explained with Examples

What Is the OWASP Top 10?

What is the OWASP Top 10? The OWASP Top 10 is a standard awareness document that ranks the ten most critical security risks to web applications. It is published by the Open Worldwide Application Security Project, a nonprofit that produces free security resources, and it is rebuilt roughly every three to four years from data contributed on real-world applications.

The important word is risks, not vulnerabilities. Each entry is a category, not a single bug. "Injection" covers SQL injection, cross-site scripting, command injection, and more, all grouped because they share a root cause: untrusted input reaching an interpreter. That grouping is what makes the list useful. You do not memorize ten thousand bugs, you understand ten patterns and recognize their variations.

OWASP builds the ranking from two sources. Most categories come from data: security vendors and testing firms submit findings mapped to Common Weakness Enumeration (CWE) identifiers across hundreds of thousands of applications, and OWASP calculates how often each weakness class appears and how much impact it carries. A smaller number of categories come from an industry survey, which catches emerging risks that automated scanners miss because tools cannot yet detect them well. Insecure Design entered the list this way.

The list matters because it became the common language of application security. Compliance frameworks reference it, job descriptions expect it, and bug bounty triagers categorize reports with it. Knowing the OWASP Top 10 is the baseline for anyone testing or defending web applications, which is why it anchors every serious web attacks course and appears on almost every offensive certification syllabus.

The OWASP Top 10 2025 List

Here is the full 2025 ranking, as published in the official OWASP Top 10 2025. Each risk below includes what it is, a concrete example, and a lab where you can exploit it yourself. Work through them in order the first time; the ranking roughly tracks how often you will meet each one in the wild.

A01:2025 - Broken Access Control

Broken access control is when an application fails to enforce what a user is allowed to do, letting them read or change data that should be off limits. It has been the number one web risk since 2021 and stayed there in 2025, now absorbing Server-Side Request Forgery as a sub-case.

The classic example is an Insecure Direct Object Reference. You view your own invoice at /invoice?id=1043, change the number to 1044, and the application hands you someone else's invoice because it checked that you were logged in but never checked that the record belonged to you. The same failure covers forced browsing to admin pages, tampering with a JWT role claim, and reaching internal services through a request the server makes on your behalf (the SSRF case now folded in here).

Practice it in the IDOR Explorer lab, escalate to an admin panel in Admin Portal Breach, or exploit the server-side request forgery variant in SSRF Validator.

A02:2025 - Security Misconfiguration

Security misconfiguration is a system left in an insecure state through defaults, oversights, or unnecessary features rather than a coding bug. It climbed from fifth in 2021 to second in 2025, which reflects how much modern breaches come from sloppy setup rather than clever exploitation.

Think default credentials left on an admin console, a cloud storage bucket set to public, directory listing enabled, verbose error pages that leak stack traces, or an exposed .git folder that hands an attacker your whole source tree. None of these require a zero-day. They require someone to notice the door was never locked.

The Git Exposed lab lets you reconstruct an application from a carelessly deployed repository, and the Web Security Basics course covers the configuration mistakes that cause this class.

A03:2025 - Software Supply Chain Failures

Software supply chain failures cover risks introduced by the components, dependencies, and build pipelines your application relies on rather than code your team wrote. In 2025 OWASP broadened the old "Vulnerable and Outdated Components" category into the full supply chain, because the way software gets built changed faster than the old name allowed.

A dependency with a known CVE that you never patched is the simplest case. Log4Shell was one library flaw that exposed millions of applications overnight. Worse are the active compromises: a maintainer account gets phished and a malicious version of a popular npm package ships to everyone who runs an update. Your code can be perfect and you still get owned through a package you never read.

Defending this class means knowing your dependencies, pinning versions, verifying signatures, and scanning your build. The Container and Kubernetes Security course covers supply chain integrity for containerized builds, where this risk concentrates.

A04:2025 - Cryptographic Failures

Cryptographic failures happen when sensitive data is not protected properly, whether through weak algorithms, missing encryption, or bad key handling. It sat at second in 2021 and moved to fourth in 2025, not because it got less serious but because misconfiguration and supply chain moved above it.

The everyday example is password storage. An application that stores passwords as unsalted MD5 hashes has effectively stored them in plaintext, because a leaked MD5 hash of a common password is cracked in milliseconds. Other cases include transmitting data over plain HTTP, hardcoding an encryption key in the source, or using a broken cipher mode that leaks patterns in the ciphertext.

To feel why weak hashing fails, crack real hashes in the Crack SHA1 Hash lab, then read our hash cracking tutorial and our explainer on why you cannot simply reverse an MD5 hash. The Password Cracking course shows the offensive side end to end.

A05:2025 - Injection

Injection is when untrusted input is interpreted as a command or query, letting an attacker change what the application does. It includes SQL injection, cross-site scripting, command injection, LDAP injection, and NoSQL injection, all sharing one root cause: data crossing into a place meant for code. Injection dropped from third in 2021 to fifth in 2025 as frameworks made the common cases harder, but it has not gone away.

The textbook case is SQL injection. A login form builds a query by pasting your input directly into a string, so entering ' OR '1'='1 as the password turns the query into one that is always true and logs you in as the first user in the table. Cross-site scripting is the same idea aimed at the browser: a comment field that echoes <script> back unescaped runs your JavaScript in every visitor's session.

Exploit SQL injection hands-on in Query Quake, one of the most popular labs on HackerDNA, and cross-site scripting in the XSS Playground. Our SQL injection tutorial and our breakdown of XSS vs CSRF go deeper on the two you will meet most.

A06:2025 - Insecure Design

Insecure design is a flaw in the intended logic of an application rather than a mistake in its implementation. You cannot patch it with a security header because the problem is the plan itself. It held at fourth in 2021 and sits at sixth in 2025, still a reminder that not every bug is a typo.

A password reset flow that sends a six-digit code but never limits how many guesses you get is insecurely designed: the code is fine, the absence of rate limiting is the hole. Business logic flaws live here too, like a checkout that lets you apply the same single-use discount a thousand times, or a transfer that accepts a negative amount and moves money the wrong way.

These need a tester who thinks about how the feature can be abused, not just whether it works. The API Logic Flaw lab is built around exactly this kind of design-level weakness.

A07:2025 - Authentication Failures

Authentication failures are weaknesses in how an application confirms who a user is and keeps them logged in. OWASP shortened the 2021 name "Identification and Authentication Failures" to just "Authentication Failures" in 2025, but the substance is the same. It stayed at seventh.

The failures cluster in a few places: allowing weak or breached passwords, not defending against credential stuffing, exposing session tokens that never expire, and mishandling JSON Web Tokens. A JWT library that accepts the alg: none header will trust a token an attacker forged with no signature at all, handing over any account they name.

Break a login in Hack the Login, walk through an authentication bypass in Auth Bypass, and forge tokens in JWT Algorithm Confusion. The JWT Hacking course covers token attacks in depth.

A08:2025 - Software or Data Integrity Failures

Software or data integrity failures occur when an application trusts code or data without verifying it has not been tampered with. The 2025 name swaps "and" for "or" but keeps the meaning from 2021. It stayed at eighth.

Insecure deserialization is the sharpest example. An application that unpickles a Python object or unserializes a PHP object from user input can be tricked into running attacker-chosen code, turning a data field into remote code execution. The category also covers auto-update mechanisms that fetch code over an unverified channel and CI/CD pipelines that deploy artifacts without checking a signature.

Get hands-on with the Pickle Deserializer lab, where a trusted serialized object becomes a shell, and the Type Juggling Bypass lab for a related integrity flaw in loose comparisons.

A09:2025 - Security Logging and Alerting Failures

Security logging and alerting failures mean an application does not record security-relevant events or does not raise an alarm when something goes wrong, so attacks go unnoticed. OWASP renamed the 2021 "Monitoring" to "Alerting" in 2025 to stress that collecting logs is useless if nobody is watching them. It stayed at ninth.

The damage here is measured in time. A site that never logs failed logins cannot tell that someone ran a credential stuffing attack for three weeks. The industry average dwell time, the gap between a breach and its detection, is still measured in weeks or months, and missing logs are a big part of why. This is the one category on the list that hurts you as a defender more than it helps you as an attacker, and it is why blue teams exist.

The defender's side of this is where log analysis lives. Practice pulling attacks out of logs in the Log Hunter lab, and see the full detection workflow in the Digital Forensics and Incident Response course.

A10:2025 - Mishandling of Exceptional Conditions

Mishandling of exceptional conditions is a brand new 2025 category covering what happens when an application meets an error or an unexpected state and handles it insecurely. It replaces SSRF in the tenth slot, since SSRF moved up into Broken Access Control.

The dangerous pattern is fail-open logic. Imagine an authorization check that throws an exception when a service is unreachable, and the surrounding code treats the exception as "allow" instead of "deny". The system fails in the attacker's favor. This class also covers verbose error responses that leak a stack trace with database credentials, and unhandled exceptions that leave the application in a half-processed, exploitable state.

The Flask Error lab shows how a mishandled exception spills sensitive detail an attacker can use, which is the everyday face of this new category.

What Changed in OWASP Top 10 2025 vs 2021

If you learned the list from the 2021 edition, most of it still holds. Broken Access Control is still first, and the middle of the list moved around without dropping much. Three changes are worth knowing.

First, two categories are effectively new. Software Supply Chain Failures grew out of the narrower 2021 "Vulnerable and Outdated Components" and now covers the whole build and dependency chain. Mishandling of Exceptional Conditions is genuinely new, added because error handling failures were showing up across breaches without a home on the list.

Second, SSRF is gone as a standalone entry. In 2021 it earned its own tenth slot on the strength of the survey; in 2025 the data placed it inside Broken Access Control, where it fits as a request the server should not have been allowed to make. It did not become less important, it got reclassified.

Third, the ranking reshuffled. Security Misconfiguration rose from fifth to second, Cryptographic Failures slipped from second to fourth, and Injection eased from third to fifth. Here is the side by side.

How to Use the OWASP Top 10

The list is a starting point, not a finish line. OWASP itself says the Top 10 is an awareness document, and treating it as your entire security program is the most common way people misuse it. How you apply it depends on which side of the application you sit on.

If You Build Software

Use the Top 10 as a design and review lens, not a bug list to clear at the end. Before a feature ships, ask the questions the list implies: does this enforce access control on every object, does it treat all input as hostile, does it log security events, does it fail closed when something breaks. Bake those into code review and you catch whole categories before they exist. Start with the fundamentals in the Web Security Basics course, which covers how these risks map to the code you write.

If You Test Software

Use the Top 10 as a coverage map so a test does not chase one shiny bug and miss a whole class. Professionals pair it with the deeper OWASP Web Security Testing Guide, which turns each risk into specific test cases with identifiers you can track. For the full engagement flow around those tests, our web application penetration testing guide shows how the pieces fit into a real assessment.

The honest caveat, worth saying plainly: the Top 10 is not exhaustive and was never meant to be. It is the ten risks that show up most, which means a determined attacker will happily use the eleventh. Learn the list to build a foundation, then keep going past it. The value is that it gives everyone, developers and testers and triagers, one shared vocabulary for the risks that matter most.

How to Test for the OWASP Top 10

You cannot learn these risks by reading about them, and you cannot legally practice them on applications you do not own. You need targets built for it. The toolset for finding Top 10 flaws is small and worth knowing well.

• Burp Suite is the intercepting proxy at the center of web testing. You will use it to tamper with access control, replay injection payloads, and inspect tokens. The free Community Edition covers everything a beginner needs.
• sqlmap automates SQL injection extraction once you have confirmed an injection point by hand. Confirm manually first, then let it do the tedious part.
• A browser and its developer tools are enough to find a surprising number of access control and misconfiguration flaws. Change an ID, read a verbose error, notice a token that never expires.
• Nuclei and dependency scanners catch the misconfiguration and vulnerable-component classes fast, which is where automation genuinely earns its place.

In practice, most real findings come from a human noticing something a scanner cannot judge. A tool flags that an object reference exists; only a person knows that object should have belonged to someone else. That gap is the whole job. The fastest way to build the instinct is to exploit each risk yourself a few times in a controlled lab until the pattern is obvious.

Legal and Ethical Considerations

The techniques in this guide are the same ones criminals use, and the only thing separating a penetration tester from a defendant is permission. Testing your own applications is legal. Testing a company's site because you spotted an open .git folder is not, however obvious the flaw or good your intentions.

There are three places to practice legally. Bug bounty programs on platforms like HackerOne and Bugcrowd grant permission to test within published rules. Paid engagements run under a signed scope document. Sandboxed lab platforms and CTF events give you targets the platform owns and offers up on purpose. Everything in this guide is meant for those three venues and nowhere else.