The OWASP Top 10 is the most widely referenced list of critical web application security risks, currently in its 2021 edition. It is not a checklist you can pass — each entry is a broad risk category covering dozens of specific weaknesses. Here is what each category actually means when your team is building and shipping software, and what to do about it.
A01: Broken Access Control
This moved to the top spot in 2021, and in our experience it belongs there. Broken access control means users can do things they should not be able to do: view another customer's records by changing an ID in a URL, call admin endpoints as a regular user, or access another tenant's data in a multi-tenant app.
The reason it is so common is simple: frameworks give you authentication almost for free, but authorisation is left to you, and it has to be enforced on every single request. Miss one endpoint and you have a vulnerability. The API-world name for the most common variant is BOLA — we cover it in detail in our guide to BOLA and IDOR.
Practical fix: centralise authorisation logic, deny by default, and scope every database query to the current user or tenant rather than trusting IDs from the client.
A02: Cryptographic Failures
This is rarely about exotic attacks on cryptography. In practice it means sensitive data that is not protected at all, or protected badly: traffic over plain HTTP, passwords hashed with MD5 or SHA-1, hardcoded keys in source code, or secrets committed to repositories.
Practical fix: TLS everywhere, a modern password hashing algorithm (bcrypt, scrypt or Argon2), a proper secrets manager, and never rolling your own crypto.
A03: Injection
Injection happens when untrusted input reaches an interpreter — SQL, an OS shell, an LDAP query, or (since XSS was folded into this category) the browser's HTML parser. The attacker's data stops being data and starts being code.
Practical fix: parameterised queries or an ORM for SQL, avoiding shell commands built from user input, and templating engines that escape output by default. Most modern frameworks make the safe path the easy path — injection bugs usually appear where someone worked around the framework.
A04: Insecure Design
New in 2021, this category covers flaws in what the application is designed to do, not mistakes in how it was coded. Think of a password reset flow with no rate limiting, an e-commerce checkout that trusts a price sent from the client, or a workflow that can be replayed to duplicate a payout.
Practical fix: threat model new features before you build them. Ask what an abusive user would do with this feature, not just whether the happy path works.
A05: Security Misconfiguration
Default credentials, verbose stack traces in production, directory listing enabled, unnecessary services exposed, missing security headers, cloud storage buckets open to the world. Nothing here is a coding bug — it is all configuration that shipped in an unsafe state.
Practical fix: hardened, repeatable build and deployment configuration, minimal installed features, and separate configs for dev and production that are actually enforced.
A06: Vulnerable and Outdated Components
Your application includes far more code you did not write than code you did. Log4Shell was the loudest recent reminder that a single vulnerable dependency can compromise everything built on it.
Practical fix: know what you run (dependency inventory), get alerted when it is vulnerable (Dependabot, Renovate or similar), and have a patch cadence that management actually resources.
A07: Identification and Authentication Failures
Weak password policies, no protection against credential stuffing, session tokens that never expire, predictable password reset tokens, and missing multi-factor authentication. Attackers rarely need a clever exploit when they can just log in.
Practical fix: MFA for anything sensitive, rate limiting and breached-password checks on login, and session handling delegated to a well-tested library rather than written in-house.
A08: Software and Data Integrity Failures
This covers trusting software and data without verifying integrity: unsigned auto-updates, CI/CD pipelines that pull and execute unverified code, and insecure deserialisation of user-controlled objects.
Practical fix: sign and verify artefacts, lock down who and what can push to your pipeline, and avoid deserialising untrusted data in formats that allow arbitrary object construction.
A09: Security Logging and Monitoring Failures
You cannot respond to what you cannot see. If failed logins, access control failures and high-value transactions are not logged and nobody is alerted on them, a breach can run for months unnoticed.
Practical fix: log security-relevant events with enough context to investigate, centralise those logs, and make sure something — or someone — is actually watching them.
A10: Server-Side Request Forgery (SSRF)
SSRF happens when your server fetches a URL supplied by a user — a webhook, an image import, a PDF generator — and an attacker points it at things only your server can reach: internal admin panels, other services, or cloud metadata endpoints that hand out credentials.
Practical fix: allowlist the destinations server-side fetches may reach, block internal IP ranges, and enforce IMDSv2 (or your cloud's equivalent) on your instances.
How to actually use the Top 10
The Top 10 is an awareness document, not a compliance standard or a complete test plan. Use it to train developers, to shape code review checklists, and as a shared vocabulary between engineering and security. Then verify with real testing: a quality web application penetration test covers every category above, plus the business logic issues no list can enumerate. If you want to see how that testing actually runs, we have written up our web app testing methodology.
FAQ
Is the OWASP Top 10 a compliance standard?
No. It is an awareness document. That said, standards such as PCI DSS reference it, and customers and auditors often ask whether your testing covers it, so treating it as a baseline is sensible.
How often is the OWASP Top 10 updated?
Roughly every three to four years, based on contributed vulnerability data and industry surveys. The 2021 edition is current; categories shift between editions, but the underlying flaws change slowly.
Does a clean vulnerability scan mean we are covered for the Top 10?
No. Scanners do reasonably well on misconfiguration and outdated components, but they are largely blind to broken access control and insecure design — the categories at the top of the list — because those require understanding what your application is supposed to allow.
If you would like your application tested against the OWASP Top 10 and beyond by experienced practitioners, get in touch — we will scope it in a short call and have a fixed quote to you within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.