What is OWASP Top 10? Complete Beginner Guide (2026)

OWASP Top 10 Explained: Complete Beginner Guide 2026 — Broken Access Control, SQL Injection, XSS, SSRF & Every Vulnerability With Real Examples

OWASP Top 10 web application security vulnerabilities guide

If you spend any time in web security, you'll hear "OWASP Top 10" mentioned constantly — in job descriptions, penetration testing reports, security certifications, and developer training. But most explanations I've seen either just read the official documentation back at you, or stay so abstract you finish reading and still don't really understand what any of it means in practice.

This post tries to be different. The OWASP Top 10 is published by the Open Web Application Security Project — a non-profit that has been tracking web application vulnerabilities since 2001. The list is built from real data: security testing firms, bug bounty programmes, and thousands of production applications. It doesn't represent theoretical risks. These are vulnerabilities that show up in real applications, every day, being actively exploited.

For each vulnerability I'm going to explain what actually goes wrong, show you a concrete attack scenario, describe the real-world impact, and tell you exactly what fixes it. By the end you should be able to recognise these issues — whether you're a developer trying to avoid them, a security tester looking for them, or a student trying to understand the field.

Quick Navigation — OWASP Top 10 (2021 Edition, still current in 2026):

A01 — Broken Access Control
A02 — Cryptographic Failures
A03 — Injection (SQL, Command, LDAP)
A04 — Insecure Design
A05 — Security Misconfiguration
A06 — Vulnerable and Outdated Components
A07 — Identification and Authentication Failures
A08 — Software and Data Integrity Failures
A09 — Security Logging and Monitoring Failures
A10 — Server-Side Request Forgery (SSRF)

A01 — Broken Access Control

Access control is the system that decides who is allowed to do what inside an application. A regular user should be able to see their own data. They should not be able to see someone else's, modify records they don't own, or reach admin functionality. Broken access control means those rules aren't enforced properly at the server level — and attackers can exploit the gap.

This is the number one vulnerability in the OWASP list for a reason. It's not that developers don't know access control matters — it's that enforcing it correctly on every route, every object, and every request is harder than it sounds, and developers often implement it inconsistently.

Real Attack Scenario

You're logged into an e-commerce site. Your order is at /orders/4521. You change the number in the URL to /orders/4520. The server checks that you're logged in — but it doesn't check whether order 4520 is yours. You now see a stranger's full name, delivery address, and order contents. This is called an Insecure Direct Object Reference (IDOR) — one of the most common forms of broken access control.

Other forms include: regular users accessing admin pages because the frontend hides the links but the backend route isn't actually protected; users escalating privileges by modifying a role parameter in a request; read-only users making write requests because only the UI button was disabled, not the API endpoint.

Impact: Unauthorised access to other users' data, account takeovers, admin-level actions by unprivileged users, data breaches at scale. Broken access control was involved in the 2021 Parler data breach — sequential media IDs with no authorisation checks allowed 32TB of data to be scraped.

How to fix it

Deny by default. If a user's access to a resource isn't explicitly granted, the answer should be no — not yes.
Check authorisation server-side on every request. Not just the route — the specific object being accessed. Does this user own this record?
Never trust client-side controls alone. Hidden buttons, disabled form fields, and JavaScript checks are not security. They're UI. The backend must enforce the same rules independently.
Use indirect references. Instead of sequential database IDs in URLs, use UUIDs or other unpredictable identifiers that are harder to enumerate.
Log and alert on access control failures — repeated 403 errors from the same IP can indicate someone probing for IDOR vulnerabilities.

A02 — Cryptographic Failures

This category covers any failure to properly protect sensitive data — passwords, payment information, health records, personal details — using cryptography. The OWASP list renamed this from "Sensitive Data Exposure" to "Cryptographic Failures" to emphasise the root cause: data is exposed because encryption is missing, weak, or incorrectly implemented.

The key distinction is between data in transit and data at rest. Data in transit travels over networks — it needs HTTPS (TLS) to prevent interception. Data at rest sits in databases and files — it needs to be encrypted or properly hashed so that even if the database is breached, the raw values can't be read or cracked.

Real Attack Scenario

A site stores user passwords as MD5 hashes. The database gets breached and the attacker downloads the hashes. Using a GPU-powered cracking tool like Hashcat and a rainbow table, they recover the original passwords for 70–80% of accounts within a few hours. The same passwords get tried on Gmail, banking sites, and other services via credential stuffing. Had the site used bcrypt or Argon2 with a salt, the same attack would take centuries per password.

Impact: Exposed passwords lead directly to account takeover across every service where that password was reused. Exposed payment data triggers PCI-DSS violations. In the 2012 LinkedIn breach, 117 million unsalted SHA1 password hashes were cracked and used for credential stuffing attacks for years afterwards.

How to fix it

Use HTTPS everywhere. Not just on login pages — on every page. Force redirects from HTTP. Use HSTS.
Hash passwords with bcrypt, scrypt, or Argon2. Never MD5, never SHA1, never SHA256 alone. These are not password hashing functions — they're general-purpose hashes that can be computed millions of times per second.
Encrypt sensitive data at rest. Credit card numbers, national IDs, health records — if you don't need to read them in plain text, don't store them that way.
Don't transmit sensitive data unnecessarily. If you don't need it, don't collect it. If you don't need to store it, don't.
Use TLS 1.2 or 1.3. Disable TLS 1.0 and 1.1 — they have known vulnerabilities.

A03 — Injection

Injection happens when untrusted user input is sent to an interpreter — a database, an operating system shell, an LDAP server, an XML parser — and the interpreter can't distinguish the legitimate command from the data an attacker has embedded in the input. The attacker's data gets executed as code.

SQL injection is the classic example, but the same class of vulnerability exists anywhere untrusted data is interpreted: OS command injection, LDAP injection, XPath injection, template injection. The root cause is always the same: mixing data and instructions without proper separation.

SQL Injection Attack Scenario

A login form takes a username. The backend builds: SELECT * FROM users WHERE username = '[input]'

An attacker enters: ' OR '1'='1' --

The query becomes: SELECT * FROM users WHERE username = '' OR '1'='1' --'

Since '1'='1' is always true, this returns all users. The -- comments out the rest. The attacker logs in as the first user in the database — usually the admin account.

Command Injection Attack Scenario

An app lets users ping a server by entering an IP. The backend runs: ping [user_input]

An attacker enters: 8.8.8.8; cat /etc/passwd

The shell runs both commands. The semicolon ends the ping. /etc/passwd gets printed to the attacker — or worse, a reverse shell is opened.

Impact: Full database exfiltration, authentication bypass, remote code execution on the server, complete system compromise. SQL injection was responsible for the 2008 Heartland Payment Systems breach — 130 million payment card records stolen.

How to fix it

Use parameterised queries / prepared statements. This is the definitive fix for SQL injection. The database driver handles separating data from the query — user input can never alter the query structure.
Never build queries by string concatenation. "SELECT * FROM users WHERE id = " + userId is dangerous regardless of what userId looks like.
Never pass user input directly to shell commands. Use language-level libraries instead of shell exec where possible. If you must use the shell, use strict allowlists for permitted input.
Use an ORM — but be aware that raw query methods in ORMs can still be vulnerable if used incorrectly.
Apply the principle of least privilege to database accounts. An application's DB user shouldn't have DROP TABLE permission.

A04 — Insecure Design

This category is different from all the others. Every other vulnerability in this list can be introduced by a developer making a mistake while implementing something that could have been done correctly. Insecure design is about a feature or system that was never designed to be secure in the first place. No amount of careful coding fixes a fundamentally broken design.

OWASP added this category in 2021 to push security left — into the design and requirements phase, not just the implementation review.

Real Attack Scenario

A password reset flow sends a 6-digit OTP to the user's email. The OTP doesn't expire for 24 hours. There's no limit on how many times you can guess. An attacker wants to take over your account — they trigger a reset, then write a script that tries all 1,000,000 possible 6-digit combinations. At 10 requests per second, they're through every possibility in under 28 hours. The code may be perfectly written. The design is broken.

Another example: an e-commerce checkout sends the cart total from the client to the server. An attacker intercepts the request with Burp Suite and changes "total": 4999 to "total": 1. Orders for expensive items go through at ₹1 because the server trusted the client-supplied price rather than calculating it from the database.

Impact: Business logic exploitation, mass fraud, account takeovers at scale. These vulnerabilities are often harder to detect in code review because the code itself looks fine — the problem is in what it's implementing.

How to fix it

Think about security during design, not after. Ask "how could this be abused?" before writing code.
Use threat modelling. Walk through user stories from an attacker's perspective. What can they submit, manipulate, replay, or skip?
Always calculate sensitive values server-side. Price, discount, quantity, role — never trust the client for anything that has a security or financial implication.
Add rate limiting and OTP expiry to any authentication flow as a design requirement, not an afterthought.
Have security engineers review designs, not just final code.

A05 — Security Misconfiguration

This is one of the most common categories because avoiding it requires active, ongoing effort. Default configurations for web servers, databases, frameworks, and cloud services are designed for ease of setup, not security. Out of the box, many components have unnecessary features enabled, default credentials in place, and verbose error output turned on. Developers set things up and move on — and those insecure defaults stay in production.

Real Attack Scenario

A developer deploys a Spring Boot application to production. The Spring Boot Actuator is enabled by default and exposes /actuator/env — a debug endpoint that dumps all environment variables, including database passwords and API keys. The endpoint is publicly accessible with no authentication. An automated scanner finds it within hours of deployment. The attacker reads the database credentials from the response and connects directly to the production database.

Other common examples: default admin credentials left unchanged (admin/admin, admin/password); debug mode left on in production, leaking stack traces and internal paths in error responses; directory listing enabled on a web server, showing every file in a directory; unnecessary HTTP methods (DELETE, PUT) left enabled on APIs; misconfigured CORS policies that accept requests from any origin.

Impact: Complete server compromise, credential theft, data breaches. The 2017 Equifax breach that exposed 147 million Americans was partially caused by an unpatched Apache Struts server — a misconfiguration of a different kind: running known-vulnerable software in production.

How to fix it

Disable or remove everything you don't need. Debug endpoints, admin interfaces, unused services, example files, default applications.
Change all default credentials immediately. Databases, admin panels, cloud consoles — assume every default password is public knowledge, because it is.
Turn off debug mode in production. Never return stack traces or detailed error messages to end users.
Configure CORS explicitly. Don't use wildcard origins (*) unless you have a specific reason and understand the implications.
Implement a hardening checklist for every environment. Automate configuration checks in your deployment pipeline.

A06 — Vulnerable and Outdated Components

Modern applications don't run on code you wrote alone. They run on frameworks, libraries, packages, and dependencies — often hundreds of them. Each of those components is a potential vulnerability vector. When a CVE (Common Vulnerabilities and Exposures) is published for a library you're using, every application running that version becomes a known target. Attackers automate scanning for these.

Real Attack Scenario

A Node.js application uses an npm dependency last updated in 2021. A critical RCE (Remote Code Execution) vulnerability was discovered in that package in 2023 and given a CVSS score of 9.8. The CVE is public. Exploit code is on GitHub. Automated scanners probe the internet for applications returning version headers or other fingerprints that indicate the vulnerable version. Your application hasn't been updated. Within days of the CVE publication, it's compromised — not through a sophisticated custom attack, but through a script a teenager downloaded.

Impact: Remote code execution, data exfiltration, server takeover. The Log4Shell vulnerability (CVE-2021-44228) in the Log4j library affected hundreds of millions of Java applications worldwide — Apache, Apple, Amazon, Microsoft. All running one vulnerable library.

How to fix it

Keep a full inventory of every dependency — direct and transitive (the dependencies of your dependencies).
Use automated dependency scanning tools: npm audit, Snyk, Dependabot, OWASP Dependency-Check. Run them in your CI/CD pipeline.
Update dependencies regularly. Not only when there's a crisis. Make it a scheduled task.
Remove unused dependencies. Every library you don't need is a vulnerability you don't need to carry.
Subscribe to security advisories for frameworks and major libraries you depend on.

A07 — Identification and Authentication Failures

Authentication is how an application confirms you are who you say you are. Failures here mean attackers can impersonate users, bypass login, or hijack active sessions. This category covers a range of issues: weak password policies, no brute-force protection, insecure session tokens, missing multi-factor authentication, and improper session expiry.

Real Attack Scenario

A banking portal allows unlimited login attempts with no lockout and no CAPTCHA. An attacker loads a list of 10,000 email addresses harvested from a previous breach and pairs them with the 100 most common passwords. Running at 5 attempts per second across all accounts, they're through the full matrix in hours. For any account where the user's password is "Password1" or "123456789", they're in. This is credential stuffing and password spraying — both made possible by missing brute-force protection.

Impact: Account takeovers, financial fraud, unauthorised access to sensitive data. Weak authentication is the entry point for most large-scale data breaches. The 2012 Dropbox breach was enabled partly by an employee using the same password on Dropbox as on a previously-breached LinkedIn account.

How to fix it

Enforce strong password requirements — but focus on length, not complexity. A 16-character passphrase is stronger than a 8-character mix of symbols.
Implement rate limiting and account lockout on login endpoints. Alert on multiple failed attempts.
Require multi-factor authentication for all accounts, especially admin and privileged users. Authenticator apps are better than SMS.
Invalidate sessions on logout. Server-side session invalidation — not just clearing a client-side cookie.
Set appropriate session timeouts. Don't keep sessions alive indefinitely.
Use secure, unpredictable session token generation. Never use sequential IDs as session tokens.

A08 — Software and Data Integrity Failures

This category, introduced in 2021, covers situations where applications trust code or data without verifying its integrity. The most prominent real-world example is supply chain attacks — where an attacker compromises a dependency or update mechanism, and that compromise propagates to every application that consumes it.

Real Attack Scenario

In the 2020 SolarWinds attack, attackers compromised SolarWinds' build pipeline and inserted malicious code into a legitimate software update. 18,000 organisations — including US government agencies — installed the update. Their security tools trusted it because it came from a known vendor with a valid signature. The application loaded a third-party JavaScript file from a CDN with no integrity check. The CDN was compromised. A malicious script was served to all visitors and silently exfiltrated form data — including passwords and credit card numbers — for three months before detection.

Impact: Silent supply chain compromise, mass credential theft, remote code execution across thousands of organisations simultaneously. Supply chain attacks are one of the most dangerous modern threat vectors because they exploit trust rather than technical vulnerabilities.

How to fix it

Use Subresource Integrity (SRI) for third-party scripts loaded from CDNs. The browser checks a hash before executing the script.
Verify the integrity of software updates using digital signatures before applying them.
Secure your CI/CD pipeline. Treat build servers with the same security rigour as production servers. Review who can modify build scripts.
Pin dependency versions and use lock files (package-lock.json, requirements.txt) to prevent unexpected updates.
Review any data that flows through deserialization — don't deserialize untrusted input without validation.

A09 — Security Logging and Monitoring Failures

This one is different in character from the others. It's not a vulnerability that directly gives an attacker access — it's a failure that allows attacks to go undetected and unchallenged once they're happening. Without adequate logging and monitoring, breaches continue for months. According to IBM's 2023 Cost of a Data Breach report, the average time to identify a breach is 204 days.

Applications often log none of the right things: failed login attempts, access control failures, invalid tokens, unusual query patterns. Even when they do log, nobody is watching or alerting on the logs in real time.

Real Attack Scenario

An attacker runs an IDOR enumeration script against an API — iterating through user IDs and retrieving profile data. Each request returns a 200 OK, which isn't logged as suspicious. Over 48 hours, 500,000 user records are exfiltrated. There are no alerts because access control failures weren't being monitored. The breach is discovered three months later when the data appears for sale on a dark web forum. The application had no way to answer: when did this happen? What was taken? How did they get in?

Impact: Breaches go undetected for months. Evidence for forensic investigation is missing. Regulatory consequences under GDPR, DPDP, and PCI-DSS are worse when you can't demonstrate you had controls in place or can't identify the scope of compromised data.

How to fix it

Log all authentication events: successes, failures, lockouts, password resets. With timestamp, IP, and user agent.
Log access control failures. A user getting a 403 once is normal. Getting 403s 500 times in 10 minutes means someone is probing.
Set up real-time alerting for suspicious patterns — not just storage of logs nobody reads.
Centralise logs. If each server keeps its own logs locally and the server is compromised, the attacker can wipe the evidence.
Protect log integrity. Logs should be append-only and ideally sent to a system the application cannot modify.
Test your detection. Run simulated attacks and verify that your monitoring would catch them.

A10 — Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a remote resource based on a URL supplied by the user, without sufficiently validating that URL. The attacker tricks the server into making requests to destinations the attacker couldn't reach directly — internal services, cloud metadata endpoints, or other systems behind a firewall.

This has become significantly more impactful with the rise of cloud computing. Cloud instances have a special metadata endpoint at 169.254.169.254 (AWS, GCP) or 169.254.169.254/metadata (Azure) that returns IAM credentials, instance information, and other sensitive configuration — and it's accessible from any process running on the instance, with no authentication.

Real Attack Scenario

A web application has a "URL preview" feature — paste a link and see a thumbnail. The backend fetches the URL server-side. An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ as the URL. The server fetches it and returns the response — which contains the AWS role credentials for the EC2 instance, including AccessKeyId, SecretAccessKey, and Token. The attacker now has full AWS access to every service that role can reach.

This is almost exactly how the 2019 Capital One breach happened — SSRF via a misconfigured WAF, AWS metadata endpoint, credentials extracted, 100 million records exfiltrated.

Impact: Internal network scanning, access to cloud credentials, lateral movement to databases and internal services, data exfiltration. Capital One: 100 million customer records. One SSRF vulnerability.

How to fix it

Validate and sanitize all user-supplied URLs. Check scheme (allow only https://), check destination against an allowlist of permitted domains.
Block requests to private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1, and 169.254.0.0/16 (link-local / cloud metadata).
Disable or restrict URL-fetching features if they aren't essential to the application's function.
On cloud infrastructure: use IMDSv2 (Instance Metadata Service version 2) on AWS, which requires a session-oriented approach that makes SSRF harder to exploit.
Enforce network-level controls: the application server should not be able to reach internal services it doesn't need to reach.

Before we get to the checklist: You don't need to fix everything at once. If you're a developer reviewing your own application, start with A01 (Broken Access Control) and A03 (Injection) — they have the widest attack surface and the most direct exploitability. If you're a security tester, A01, A03, and A10 are the most commonly found in modern applications.

OWASP Top 10 Prevention Checklist — What to Verify in Every Application

Access control: Check authorisation server-side on every request for every object. Deny by default. Never trust client-side role or permission values.
Cryptography: HTTPS everywhere. Passwords hashed with bcrypt or Argon2. Sensitive data at rest encrypted. No TLS 1.0/1.1.
Injection: Parameterised queries for all database access. No string concatenation in SQL or shell commands. Input validated against allowlists.
Design review: Threat model new features before building. All security-sensitive values calculated server-side. Rate limiting and OTP expiry are design requirements, not afterthoughts.
Configuration hardening: Debug mode off in production. Default credentials changed. Unused endpoints, features, and HTTP methods disabled. CORS configured explicitly.
Dependency management: Automated scanning in CI/CD. Dependencies updated on a schedule. Unused packages removed.
Authentication: MFA available and encouraged. Rate limiting on login. Sessions invalidated on logout. Unpredictable session tokens.
Integrity: SRI hashes on third-party scripts. Build pipeline access controls reviewed. Dependency versions pinned.
Logging: Authentication events logged. Access control failures logged. Alerts configured for suspicious patterns. Logs centralised and protected.
SSRF: URL allowlists for any fetch functionality. Private IP ranges blocked. Cloud metadata endpoint protected.

Related Posts on This Blog

About the Author

Amardeep Maroli

MCA student and cybersecurity enthusiast from Kerala, India. I focus on API security, ethical hacking, and building secure web applications using Node.js, React, and Python. I actively work on real-world vulnerability testing, security automation, and hands-on learning in cybersecurity.

I share practical guides, real attack scenarios, and beginner-to-advanced cybersecurity knowledge to help others learn security the right way — through understanding, not just tools.

OWASP Top 10 FAQs

What exactly is the OWASP Top 10?

It's a regularly updated list of the 10 most critical web application security risks, published by the Open Web Application Security Project. The list is data-driven — compiled from real vulnerabilities found across thousands of production applications by security testing firms and bug bounty programmes. The current edition is from 2021 and remains the industry standard reference in 2026.

Do I need to memorise all 10 vulnerabilities?

Not necessarily memorise — but you should understand each one well enough to recognise it. If you're a developer, focus on A01 (Broken Access Control), A02 (Cryptographic Failures), and A03 (Injection) first — these are the most commonly exploited and the most directly preventable through coding practices. The others require more architectural thinking.

Is the OWASP Top 10 only relevant for web developers?

No. It's essential reading for security testers and penetration testers (these are the most commonly found vulnerabilities). It's useful for DevOps engineers who deploy and configure applications (A05, A06, A09 are especially relevant). It's also a standard reference for security certifications like CEH, OSCP, and BSCP.

What's the difference between XSS and SQL injection?

Both are injection vulnerabilities, but they target different interpreters and have different effects. SQL injection sends malicious input to a database interpreter — it can leak, modify, or delete database data. XSS (Cross-Site Scripting) injects malicious JavaScript into a web page seen by other users — it runs in the victim's browser and can steal cookies, redirect users, or perform actions on their behalf. XSS is categorised under A03 — Injection in the current OWASP list.

Where can I practice finding these vulnerabilities?

OWASP themselves maintain WebGoat and Juice Shop — intentionally vulnerable web applications you can run locally and attack safely. PortSwigger Web Security Academy (free) has guided labs for every OWASP category. HackTheBox and TryHackMe have real-world CTF challenges. These are the right places to build hands-on skill — not live websites.