The OWASP Top 10

Every year, millions of web applications get compromised - not because attackers discovered exotic zero-days, but because developers repeated the same ten categories of mistakes. The OWASP Top 10 is the security community's attempt to name those patterns, and it has become the closest thing to a universal curriculum for web security. Think of this lesson as your map: every technique in this module traces back to one of these categories.

What Is OWASP?

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation that produces free, community-driven security research. The OWASP Top 10 is a list updated roughly every three to four years based on real vulnerability data collected from thousands of organizations and security researchers. The 2021 edition (the current one as of this writing) drew from data representing over 500,000 applications.

It is not a complete vulnerability taxonomy. It is a prioritized list of the highest-impact, most common risk categories - the things that get companies breached repeatedly.

A01 - Broken Access Control

What it is: The application fails to properly enforce what authenticated users are allowed to do. A user can access another user's data, perform admin actions, or reach URLs they were never meant to reach.

Root cause: Authorization checks are missing, inconsistent, or enforced only on the client side (easy to bypass). Developers often protect menus from appearing in the UI but forget to protect the underlying API endpoints.

Real-world example: In 2020, researchers found that a major e-commerce platform exposed order details at predictable URLs like /api/orders/1001, /api/orders/1002. Any authenticated user could increment the ID and view - or in some cases modify - every other customer's order. No admin privilege was needed, just a valid session and Burp Suite. This is Insecure Direct Object Reference (IDOR), the most common flavor of broken access control.

What to look for: Horizontal privilege escalation (user A accessing user B's data), vertical privilege escalation (regular user accessing admin functions), forceful browsing to /admin or /internal paths, missing access controls on API endpoints that the front-end "hides."

A02 - Cryptographic Failures

What it is: Sensitive data is exposed because it is stored or transmitted without adequate cryptographic protection - or with protection that has been broken (MD5 passwords, self-signed certificates accepted by code, keys hardcoded in source).

Root cause: Developers either skip encryption entirely for "internal" data, use deprecated algorithms out of habit, or mis-implement strong algorithms (ECB mode, no IV randomization, reusing nonces).

Real-world example: The LinkedIn breach of 2012 exposed 6.5 million password hashes - all unsalted SHA-1. Attackers cracked the majority within days using rainbow tables. By 2016, a second data set of 117 million accounts from the same breach surfaced. A single missing line of code - bcrypt instead of SHA1 - would have made this breach orders of magnitude less damaging. LinkedIn now uses bcrypt, but only after the lesson was learned the hard way.

What to look for: Passwords stored as MD5 or SHA-1 without salt, HTTP instead of HTTPS for login or data endpoints, API keys or secrets in JavaScript source, weak TLS configurations (TLS 1.0, RC4, NULL cipher suites), unencrypted backups.

A03 - Injection

What it is: User-controlled data is interpreted as code or a command by an interpreter - SQL, OS shell, LDAP, XML parsers, template engines. The attacker's input escapes the "data lane" and enters the "code lane."

Root cause: Applications concatenate user input directly into queries or commands instead of using parameterized interfaces. This is one of the oldest and most studied vulnerability classes, yet it refuses to die.

Real-world example: In 2008, Heartland Payment Systems - which processed 100 million card transactions per month - was breached via SQL injection against their web application. Attackers installed packet sniffers on internal systems and stole an estimated 130 million credit card numbers. It remains one of the costliest data breaches in history, resulting in over $140 million in settlements.

What to look for: Any input that gets incorporated into a database query, OS command, file path, or expression evaluator. SQL injection, NoSQL injection, command injection, template injection, LDAP injection, and XPath injection are all children of this parent category.

A04 - Insecure Design

What it is: A class of weaknesses introduced at the design and architecture phase - before a single line of code is written. No patch can fix a fundamentally flawed design.

Root cause: Threat modeling is skipped or done superficially. Teams move fast and assume business logic problems are "edge cases." Security requirements are not defined early.

Real-world example: A fintech application allowed users to reset their password by answering a security question. The design flaw: the system allowed unlimited attempts on the security question endpoint, the questions were predictable ("What is your mother's maiden name?"), and social media made the answers trivially researchable. No code bug - a pure design failure. An attacker could take over any account given a target's name and a few minutes of OSINT.

What to look for: Rate limiting absent from sensitive functions, password reset flows that leak whether an email exists (user enumeration), business logic that can be bypassed by changing a hidden form field (price=0), workflows that assume steps are completed in order when they can be skipped.

A05 - Security Misconfiguration

What it is: Default configurations, unnecessary features, unpatched systems, improperly set cloud storage permissions, verbose error messages - the application's configuration is insecure rather than its code.

Root cause: Security configuration is treated as an afterthought. Dev environments get promoted to production. Default credentials on frameworks and middleware are never changed. Cloud S3 buckets are left public.

Real-world example: In 2019, a Fortune 500 company left an AWS S3 bucket publicly readable. It contained years of internal HR documents, employee PII, and salary data. The bucket name was guessable (company-name-hr-docs). No exploit required - aws s3 ls s3://company-name-hr-docs returned the full file listing. This type of misconfiguration is discovered regularly by researchers running automated bucket enumeration tools.

What to look for: Default credentials on admin panels (admin/admin, admin/password), directory listing enabled on web servers, stack traces exposed in error messages, verbose headers (X-Powered-By: PHP/5.6, Server: Apache/2.2.14), cloud storage with public ACLs, open Redis/MongoDB/Elasticsearch instances accessible without auth.

A06 - Vulnerable and Outdated Components

What it is: The application uses libraries, frameworks, or runtime components with known, published vulnerabilities. The application is secure in its own code but ships with insecure dependencies.

Root cause: Dependency management is tedious. Teams install a library, it works, and it never gets updated until something breaks. Security patches in open-source libraries don't generate the same urgency as feature releases.

Real-world example: The 2017 Equifax breach - which exposed Social Security numbers, birth dates, and addresses of 147 million Americans - was caused by a known vulnerability in Apache Struts (CVE-2017-5638). A patch had been available for two months before exploitation began. Equifax failed to apply it to every system. The entire breach was preventable by updating one dependency.

What to look for: Outdated JavaScript libraries in page source (jQuery 1.x, old Angular versions), WordPress plugins with known CVEs, Node.js packages with published vulnerabilities (npm audit), Java frameworks with deserialization gadgets, running whatweb or wappalyzer to fingerprint technology versions.

A07 - Identification and Authentication Failures

What it is: Weaknesses in how users are identified, authenticated, and their sessions managed. Includes weak passwords, broken session tokens, credential stuffing exposure, and insecure "remember me" implementations.

Root cause: Authentication is hard to get right, and developers frequently build custom implementations instead of using vetted frameworks. Sessions are managed carelessly.

Real-world example: In 2013, Adobe suffered a breach of 153 million account records. The password hints - stored in plaintext alongside encrypted passwords - effectively revealed the passwords for millions of accounts. Worse, the encryption used was 3DES in ECB mode, which meant identical passwords produced identical ciphertext, making frequency analysis trivial. You could see that 1.9 million users shared the same most-common password just by looking at which ciphertext appeared most often.

What to look for: No account lockout after failed logins (enables brute-force), session tokens that are predictable or don't rotate after login, passwords transmitted over HTTP, session IDs exposed in URLs, JWT tokens signed with none algorithm or weak secrets.

A08 - Software and Data Integrity Failures

What it is: Code and data are loaded from external sources without verifying their integrity. Insecure deserialization is the classic sub-category: applications deserialize attacker-controlled data and execute malicious object graphs.

Root cause: Supply chain assumptions - "we trust npm/PyPI/Maven to serve us what we asked for." Auto-update mechanisms that fetch over HTTP without signature verification. Deserialization without type constraints.

Real-world example: The SolarWinds supply chain attack (2020) was the defining case. Attackers compromised SolarWinds' build pipeline and inserted a backdoor into signed software updates delivered to 18,000 organizations including US government agencies. Every customer who auto-updated received the malicious build. The signature was valid - the build process itself was compromised.

What to look for: CI/CD pipelines that pull dependencies at build time without lockfiles, npm/PyPI packages with slightly misspelled names (typosquatting), Java serialized objects in cookies or POST bodies (identified by AC ED 00 05 magic bytes in hex), PHP unserialize() calls on user input, YAML deserialization with custom constructors.

A09 - Security Logging and Monitoring Failures

What it is: The application fails to log security-relevant events (failed logins, access control violations, input validation failures) or the logs are not monitored or alerted on. Attackers can operate undetected for months.

Root cause: Logging is treated as an operational concern, not a security one. No one defines what needs to be logged. Logs go to files that nobody reads. Alert fatigue means genuine signals get buried.

Real-world example: The average time between initial compromise and detection has historically been measured in months - the 2020 Verizon DBIR found a median of 56 days. In high-profile breaches, attackers often operated for six months to a year before anyone noticed. In many cases, the victim organization was not the one who detected the breach - a third party, law enforcement, or the attacker themselves (publishing stolen data) made the first notification.

What to look for: Login endpoints with no rate limiting and no failed-attempt logging, access control violations that return an error to the user but generate no server-side alert, applications that log at INFO level but have no ERROR or WARN entries in security-relevant code paths, log files that are world-readable (log injection can also corrupt them).

A10 - Server-Side Request Forgery (SSRF)

What it is: The application fetches a remote resource based on a URL supplied or influenced by the user. An attacker can point that URL at internal infrastructure - the cloud metadata endpoint, internal APIs, or other services that should not be reachable from the internet.

Root cause: Web hooks, URL previews, PDF generators, and image importers all need to fetch external URLs. The path from "fetch this URL" to "fetch any URL including internal ones" is shorter than most developers realize.

Real-world example: The 2019 Capital One breach was facilitated by an SSRF vulnerability in a misconfigured AWS WAF. An attacker used the SSRF to reach the EC2 Instance Metadata Service (IMDS) at http://169.254.169.254/latest/meta-data/iam/security-credentials/, retrieved temporary IAM credentials, and used those credentials to download over 100 million credit card applications from S3. One SSRF plus one over-permissioned IAM role equaled the largest financial services breach of the decade.

What to look for: Any parameter that accepts a URL (url=, src=, dest=, redirect=, webhook=), PDF generation services, image importers, link preview features. Test by pointing at http://169.254.169.254/ (AWS metadata), http://localhost/, or http://169.254.169.254/latest/meta-data/ and checking if the response differs from a random external URL.

How These Categories Relate

The Top 10 is not ten independent silos. Real attacks chain multiple categories:

• An attacker uses Recon (A05 misconfiguration reveals version info) to identify a Vulnerable Component (A06), exploits it to gain a foothold, then escalates using Broken Access Control (A01) to reach admin functions, all while the breach goes unnoticed because of Logging Failures (A09).
• SSRF (A10) leads to credential theft which enables Authentication Failures (A07) via stolen session tokens.

Understanding the map means seeing those chains before attackers do.

Key Takeaways

• The OWASP Top 10 (2021) represents the highest-impact, most common web vulnerability categories - not a complete list, but the best starting point.
• Broken Access Control (A01) is the number-one category and manifests most often as IDOR: incrementing an ID in a URL or API call to access another user's data.
• Injection (A03) happens when user input escapes the data lane and enters the code lane of a query, command, or parser.
• Cryptographic Failures (A02) are often about what is missing - no HTTPS, no salting, deprecated algorithms - not exotic math failures.
• Security Misconfiguration (A05) and Vulnerable Components (A06) are the two easiest categories to find with automated tooling and the ones most often fixed by process change, not code change.
• Real attacks chain multiple categories. Knowing the map helps you spot those chains.