The OWASP Top 10 is a regularly updated list of the ten most critical security risks facing web applications, published by the non-profit Open Worldwide Application Security Project. It’s the de facto starting checklist for developers, security teams, and site owners — a shared language for “the things most likely to get a web app hacked.” Here’s what each risk means, in plain English, and where to learn more.
Reviewed and kept current by the Coppers.io editorial team — see how we research .
What the OWASP Top 10 is (and isn’t)
OWASP compiles the list from real-world vulnerability data across hundreds of organisations, then ranks the categories by how common and how serious they are. It’s awareness and prioritisation, not an exhaustive standard — clearing the Top 10 doesn’t make an app “secure,” but ignoring it almost guarantees trouble. OWASP refreshes the list every few years; the categories below are from the widely used OWASP Top 10:2021 edition, so always check owasp.org for the latest revision.
The OWASP Top 10, explained simply
| # | Risk | In one line |
|---|---|---|
| A01 | Broken Access Control | Users can reach data or actions they shouldn’t — the #1 risk. |
| A02 | Cryptographic Failures | Sensitive data isn’t properly encrypted in transit or at rest. |
| A03 | Injection | Untrusted input (e.g. SQL) is run as code or commands. |
| A04 | Insecure Design | Security flaws baked in at the design stage, before any code. |
| A05 | Security Misconfiguration | Insecure defaults, open settings, or unpatched configs. |
| A06 | Vulnerable & Outdated Components | Using libraries or software with known holes. |
| A07 | Identification & Authentication Failures | Weak login, session, or credential handling. |
| A08 | Software & Data Integrity Failures | Trusting code or updates that haven’t been verified. |
| A09 | Security Logging & Monitoring Failures | Attacks go unnoticed because nothing is logged or watched. |
| A10 | Server-Side Request Forgery (SSRF) | The server is tricked into making requests to places it shouldn’t. |
A01: Broken Access Control
The most common risk. It’s when the rules that decide who can do what fail — a regular user editing another person’s account, or reaching an admin page by guessing a URL. Enforce permissions on the server, deny by default, and never rely on hiding links.
A02: Cryptographic Failures
Sensitive data — passwords, payment details, personal info — left exposed because encryption is missing, weak, or misused. The baseline fix is encrypting data in transit with HTTPS; see what HTTPS is and the role of an SSL/TLS certificate .
A03: Injection
When an app passes untrusted input straight into a database query or command, an attacker can inject their own. Classic SQL injection lives here. The defense is treating input as data, never code — using parameterised queries and validation.
A04: Insecure Design
A newer category recognising that some flaws come from the blueprint, not the implementation. No amount of clean coding fixes a fundamentally insecure design. The answer is threat modelling and security thinking from the start.
A05: Security Misconfiguration
Default passwords left in place, verbose error messages, unnecessary features enabled, missing security headers. Extremely common and often easy to exploit — and easy to fix with hardening and patching.
A06: Vulnerable and Outdated Components
Modern apps are built on countless third-party libraries. If any has a known vulnerability and you haven’t updated, you’ve inherited the hole. Keep an inventory and patch promptly — outdated plugins are a leading cause of WordPress security breaches.
A07: Identification and Authentication Failures
Weak passwords, no rate limiting, broken session handling, missing multi-factor authentication. This is where strong logins and 2FA matter at the application level.
A08: Software and Data Integrity Failures
Trusting code, updates, or data from sources you haven’t verified — including compromised software supply chains and insecure CI/CD pipelines. Verify signatures and integrity before you trust.
A09: Security Logging and Monitoring Failures
If you don’t log security events and watch them, breaches can run for months undetected. Good logging and alerting turn a silent compromise into a caught one.
A10: Server-Side Request Forgery (SSRF)
An attacker makes your server fetch a URL of their choosing, potentially reaching internal systems behind your firewall. Validate and restrict where your server is allowed to send requests.
How site owners should use it
You don’t need to be a developer to benefit. Use the Top 10 as a prioritised checklist: keep components patched (A06), enforce HTTPS (A02), use strong authentication and 2FA (A07), and lock down configuration (A05). For a broader, non-developer view, our website security guide ties these together.
The bottom line
The OWASP Top 10 is the web’s shared shortlist of what most often goes wrong — led by broken access control, cryptographic failures, and injection. It won’t make an application bulletproof on its own, but it’s the single best starting point for focusing security effort where it matters. Treat it as a living checklist, and check OWASP for the current edition.
FAQs
- It's a regularly updated list of the ten most critical web application security risks, published by the non-profit OWASP. Built from real-world vulnerability data, it helps developers and organisations prioritise the issues most likely to lead to a breach.
- In the 2021 edition, Broken Access Control (A01) is the top risk. It covers cases where users can access data or perform actions beyond their permissions, such as viewing another user's account or reaching admin functions they shouldn't.
- OWASP revises the list every few years as the threat landscape shifts — recent editions appeared in 2017 and 2021. Always check owasp.org for the most current version, since categories and rankings change between editions.
- No. Developers use it to write safer code, but site owners, security teams, and managers can use it as a prioritised checklist. Many items — patching components, enforcing HTTPS, using strong authentication — are decisions non-developers can drive.
- It's a strong start, not a guarantee. The Top 10 covers the most common and severe risks, but real security also requires testing, monitoring, secure design, and keeping up with new threats. Think of it as essential foundations rather than a complete solution.