The OWASP Top 10 is the most widely referenced list of web application security risks in the industry. It's maintained by the Open Worldwide Application Security Project and updated periodically based on real-world data. If you build or buy web software, understanding it is the fastest way to reason about where your risk actually lives.
This guide walks through the current (2021) categories in plain language — what each one means, why it matters, and how to reduce your exposure.
A01 — Broken Access Control
The number-one risk, and the one I find most often. Broken access control means a user can act outside their intended permissions — reading another tenant's data by changing an ID in the URL, accessing an admin endpoint directly, or escalating from a normal user to an administrator.
Prevention comes down to enforcing authorization on the server for every request, denying by default, and never trusting the client to hide functionality. Object-level checks (does this user own this record?) must happen on the backend, every time.
A02 — Cryptographic Failures
Previously called 'Sensitive Data Exposure.' This covers weak or missing encryption of data in transit and at rest — serving pages over HTTP, storing passwords without a strong hash, using outdated algorithms, or hard-coding keys. The fix: enforce TLS everywhere, hash passwords with bcrypt/argon2, and manage keys properly.
A03 — Injection
Injection happens when untrusted input is interpreted as a command — SQL injection is the classic example, but it also includes NoSQL, OS command, and template injection. The defense is parameterized queries and prepared statements, plus strict input validation. Never build queries by concatenating user input.
A04 — Insecure Design
A newer category that recognizes some flaws are baked into the design, not the code. A password reset flow that leaks whether an account exists, or a checkout that can be manipulated to change the price, is an insecure design. Threat modeling early and building security requirements into features is how you address it.
A05 — Security Misconfiguration
Default credentials, verbose error messages, unnecessary features left enabled, missing security headers, and misconfigured cloud storage all live here. It's one of the most common and most preventable categories. Harden defaults, disable what you don't use, and review your configuration as part of every deploy.
A06 — Vulnerable and Outdated Components
Modern apps are mostly third-party dependencies, and a known vulnerability in one of them is a known vulnerability in your product. Track your dependencies, monitor for advisories, and patch promptly. Automated dependency scanning in CI is the baseline here.
A07 — Identification and Authentication Failures
Weak passwords, missing brute-force protection, flawed session management, and broken multi-factor flows all fall here. Use a proven authentication library rather than rolling your own, enforce sensible password policies, rate-limit login, and invalidate sessions correctly on logout and password change.
A08 — Software and Data Integrity Failures
This covers trusting code or data without verifying its integrity — insecure deserialization, unsigned auto-updates, or a compromised CI/CD pipeline pushing malicious code. Verify integrity of what you consume, sign artifacts, and secure your build pipeline as carefully as your production systems.
A09 — Security Logging and Monitoring Failures
You can't respond to what you can't see. Missing or inadequate logging means breaches go undetected for months. Log authentication events, access-control failures, and high-value actions, and make sure someone or something is actually watching those logs.
A10 — Server-Side Request Forgery (SSRF)
SSRF lets an attacker make your server send requests to destinations they choose — often internal services and cloud metadata endpoints that should never be reachable. It's especially dangerous in cloud environments. Validate and allow-list outbound destinations, and don't let user input drive server-side requests unchecked.
How the Top 10 fits into a real pentest
The Top 10 is a starting framework, not a complete checklist. A real penetration test uses it as scaffolding and then goes deeper — chaining a medium-severity information leak with a broken access control to demonstrate full account takeover, for example. Categories tell you where to look; skilled manual testing tells you what an attacker could actually do.
Attackers don't care which OWASP category a flaw belongs to. They care whether it gets them your data. Neither should your defense stop at the label.
If you want to know where your application stands against these risks — and, more importantly, what a real attacker could chain together — a manual web application penetration test is the most direct way to find out.
Written by Jalwan, freelance web application penetration tester.
Book a security assessment →