OWASP Top 10 Vulnerabilities Explained with Examples (2025)

What Is the OWASP Top 10?

The OWASP Top 10 is a list of the ten most critical web application security risks, published by the Open Web Application Security Project. It's updated every few years based on real-world vulnerability data from hundreds of organisations and penetration testers worldwide.

If you're learning web security, bug bounty, or penetration testing — the OWASP Top 10 is your syllabus. These aren't theoretical vulnerabilities from textbooks. They're the exact weaknesses that show up in production apps every day. Companies like Meta, Google, and PayPal pay bounties for them constantly.

A01: Broken Access Control

The #1 vulnerability in the world.Broken access control happens when an application doesn't properly enforce what authenticated users are allowed to do.

The most common form is IDOR (Insecure Direct Object Reference). A user can view their own invoice at /invoice?id=1001 — but what happens if they change the ID to 1002? If the server doesn't check ownership, they just read someone else's invoice.

GET /api/users/1337/profile   ← your profile
GET /api/users/1338/profile   ← another user's profile

If both return 200 OK with data → broken access control.

Other examples include accessing admin endpoints without admin role, bypassing authentication by manipulating tokens, and privilege escalation via forced browsing.

A02: Cryptographic Failures

Previously called "Sensitive Data Exposure", this category covers failures in how applications protect data at rest and in transit. The root cause is almost always a cryptography mistake.

Common failures:

• —Transmitting passwords or credit card numbers over plain HTTP instead of HTTPS
• —Storing passwords with weak or no hashing (MD5, SHA1 without salt)
• —Using deprecated encryption algorithms (DES, RC4, ECB mode AES)
• —Hard-coded cryptographic keys in source code
• —Insufficient key length or improper IV reuse

If you crack a leaked database and the passwords are MD5 hashed, that's a cryptographic failure. If an app sends auth tokens over HTTP, that's a cryptographic failure. Hashcat can crack millions of MD5 hashes per second on a laptop.

A03: Injection

Injection vulnerabilities happen when untrusted user input is sent to an interpreter as part of a command or query. The interpreter can't tell the difference between legitimate input and an attacker's payload.

SQL injection is the most notorious form. A login form that builds queries with string concatenation can be exploited with a single quote:

Normal:  SELECT * FROM users WHERE username='alice' AND password='pass'
Attack:  SELECT * FROM users WHERE username='admin'--' AND password='anything'
Result:  Admin login without knowing the password.

Other injection types include Command Injection (shell commands via user input), LDAP Injection, XPath Injection, andNoSQL Injection. The principle is the same: user input reaches an interpreter without proper sanitisation.

A04: Insecure Design

Insecure design is a category introduced in 2021 that covers design-levelflaws, not implementation bugs. Even perfect code can't fix a fundamentally broken design.

Classic example: a "forgot password" flow that lets users answer a security question to reset their password. Even if implemented correctly, security questions are inherently weak — the design is broken. Other examples:

• —Allowing unlimited login attempts (enables brute force by design)
• —Sending password reset tokens via plaintext email with no expiry
• —Multi-step checkout flows with no server-side validation at each step
• —Business logic that allows negative quantities in e-commerce

A05: Security Misconfiguration

The most common finding in penetration tests. Security misconfiguration happens when systems are deployed with insecure default settings, incomplete configuration, or unnecessary features enabled.

• —Default credentials still in use (admin:admin)
• —Directory listing enabled on web servers
• —Stack traces exposed to users (revealing framework, language, file paths)
• —XML external entity processing enabled
• —Cloud storage buckets with public read access
• —Missing security headers (CSP, X-Frame-Options, HSTS)

The most impactful misconfigs in bug bounty are exposed admin panels, publicly readable S3 buckets, and verbose error messages leaking server internals.

A06: Vulnerable and Outdated Components

Using libraries, frameworks, or other software with known vulnerabilities. This is how Log4Shell (CVE-2021-44228) was able to affect millions of systems — the vulnerable component (Log4j) was buried deep inside countless applications as a dependency.

As a pentester, tools like nuclei and nmap --script vuln scan for known CVEs in running software. A single unpatched component can hand an attacker RCE on your server.

# Find what versions are running
nmap -sV --script vulners target.com

# Nuclei scans for known CVEs automatically
nuclei -u https://target.com -t vulnerabilities/

A07: Identification and Authentication Failures

Previously "Broken Authentication". This covers weaknesses in how applications identify users and manage sessions. Authentication is hard to get right.

• —No brute-force protection on login — attackers can try millions of passwords
• —Weak or predictable session tokens (sequential IDs, short tokens)
• —Sessions not invalidated on logout
• —Credentials transmitted in URL parameters (appear in server logs)
• —Missing multi-factor authentication for sensitive accounts
• —Insecure "remember me" functionality

One of the most overlooked: after logout, the old session token should be invalidated on the server. Many apps only clear the client-side cookie — meaning anyone who grabbed the token earlier can still use it.

A08: Software and Data Integrity Failures

This covers assumptions about software updates, CI/CD pipelines, and serialised data without verifying integrity. The SolarWinds attack is the canonical example — malicious code was injected into a trusted software update.

In web security, the most common form is insecure deserialisation. Applications that deserialise untrusted data can be exploited to achieve remote code execution if the deserialisation library processes malicious payloads without validation.

# A malicious serialised Java object that triggers RCE on deserialisation
# Detected via Content-Type: application/x-java-serialized-object
# Tools: ysoserial, URLDNS chain

Also covered here: loading JavaScript from untrusted CDNs without Subresource Integrity (SRI) checksums, allowing a compromised CDN to serve malicious scripts.

A09: Security Logging and Monitoring Failures

Applications that don't log security events — or log them but never alert on them — give attackers the time to persist, escalate, and exfiltrate data undetected. The average dwell time (time between breach and detection) is still measured in weeks.

What should be logged (and alerted on):

• —Failed login attempts, especially in volume (brute force indicator)
• —Access to sensitive resources (admin panels, user PII)
• —Input validation failures — someone probing your app
• —Unusual API usage patterns outside normal hours or volumes

From a penetration testing perspective: if you can run hundreds of SQLi payloads against a login form and there's no lockout, no alert, and no block — the app has a logging/monitoring failure as well as an injection vulnerability.

A10: Server-Side Request Forgery (SSRF)

SSRF vulnerabilities let an attacker make the server issue HTTP requests on their behalf. The server acts as a proxy, often with access to internal resources the attacker can't reach directly.

# App has a URL fetch feature
POST /fetch
{"url": "https://legitimate-site.com/image.png"}

# SSRF attack: target internal metadata service
POST /fetch
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

# Returns AWS IAM credentials → full account compromise

SSRF is particularly devastating in cloud environments. AWS, GCP, and Azure all expose instance metadata services at internal IP addresses. If you can trigger SSRF on a cloud-hosted app, you can often steal credentials with instance-level permissions — which sometimes means account takeover.

How to Actually Learn the OWASP Top 10

Reading about these vulnerabilities is step one. The only way to truly understand them is to exploit them yourself — on purpose-built vulnerable machines where you can try every payload without consequence.

The OWASP Top 10 course on hackr.gg is free and covers all ten categories with interactive questions and real lab machines. You don't need to install anything — the labs spin up in your browser.

After you understand each category, put it into practice in the hacking labs:

• —A01 Broken Access Control → IDOR labs, access control bypass labs
• —A03 Injection → SQL injection labs with real MySQL and PostgreSQL
• —A07 Auth Failures → Broken auth labs, session hijacking scenarios
• —A10 SSRF → SSRF labs targeting internal services

Theory without practice doesn't build the muscle memory you need for bug bounty or a real pentest. The OWASP Top 10 is where every web security career starts.