The OWASP Top 10: 2021 explains ten broad categories of web application security risk. It gives developers, business owners, product teams, and security professionals a shared way to discuss problems that can expose data, compromise accounts, interrupt services, or damage trust.
OWASP is the Open Worldwide Application Security Project, a nonprofit foundation that publishes open security guidance. The Top 10 is its best-known awareness document. It is useful because it turns a large subject into ten understandable areas, but it is not a certification or a complete list of everything that can go wrong.
The ten categories in plain language
The numbering does not predict the exact risk to every organisation. Your priorities should depend on the application, the data it handles, who can reach it, and what would happen if a control failed.
| Category | What it means | Everyday example |
|---|---|---|
| A01 Broken Access Control | A person can view data or perform actions beyond the permissions of their account. | Changing an account number in a request reveals another customer’s invoice, or a normal user can open an administrator function. |
| A02 Cryptographic Failures | Sensitive information is not adequately protected during storage or transmission. | Passwords are stored in a reversible form, private data travels without HTTPS, or encryption keys are exposed with the application. |
| A03 Injection | Untrusted input is treated as part of a command or query instead of ordinary data. | A search field changes a database query, or a form value causes the server to execute an unintended operating-system command. |
| A04 Insecure Design | The application was designed without controls needed to prevent a realistic form of abuse. | A gift-card balance can be checked without meaningful limits, allowing an attacker to test thousands of card numbers even though the feature contains no coding error. |
| A05 Security Misconfiguration | Unsafe settings, excessive permissions, unnecessary features, or exposed diagnostic information weaken the system. | A default administrator account remains active, directory listings are public, or an error page reveals internal details. |
| A06 Vulnerable and Outdated Components | Software with known security weaknesses remains part of the application or its supporting system. | An unpatched WordPress plugin, JavaScript package, framework, or server component provides a known route into the application. |
| A07 Identification and Authentication Failures | Login, password recovery, session, or identity checks do not reliably protect accounts. | Password reset tokens remain valid too long, sessions are not ended after logout, or repeated login attempts have no sensible protection. |
| A08 Software and Data Integrity Failures | The system trusts software, updates, build processes, or structured data without confirming integrity. | A compromised update source delivers altered code, or a deployment process accepts unreviewed changes directly into production. |
| A09 Security Logging and Monitoring Failures | Important security events are not recorded, reviewed, or acted on in time. | Hundreds of failed logins and a new administrator account appear in the logs, but nobody receives an alert or investigates. |
| A10 Server-Side Request Forgery | An attacker persuades the server to request a destination the user should not be able to reach directly. | An image-import feature accepts any URL and can be used to request an internal administration service or cloud metadata address. |
What these risks look like in a real application
The categories often overlap. Consider an online customer portal. Broken access control could expose another customer’s records. Weak authentication could let an attacker take over an account. An outdated plugin might provide the first entry point, while inadequate logging delays discovery. The incident belongs to several categories because security failures rarely occur in isolation.
Risks that expose accounts and data
Broken access control, cryptographic failures, injection, and authentication failures can lead directly to exposed records or compromised accounts. Useful prevention includes checking permissions on every sensitive request, protecting data according to its importance, keeping queries separate from user input, and designing secure login and recovery flows.
Risks created by design and maintenance decisions
Insecure design begins before code is written. Teams should ask how a useful feature might be abused and decide on limits, approvals, verification, and recovery. Security misconfiguration and outdated components require clear ownership after launch. Someone must know which software is running, which settings matter, and how updates are tested and applied.
Risks that weaken trust in software and operations
Software integrity problems can begin in a dependency, update channel, or deployment process. Logging failures allow other attacks to continue unnoticed. Server-Side Request Forgery shows why a server should not trust every destination supplied by a user. These areas connect application security to development practices, hosting, monitoring, and incident response.
How organisations should use the Top 10
Use it first as a conversation guide. For every important feature, ask which categories could affect the data, users, and business process. A password reset feature should raise questions about identity checks, token protection, rate limits, logging, and recovery if an account is compromised.
Next, turn the relevant risks into requirements that can be tested. “Prevent broken access control” is too broad. “A customer can read only invoices assigned to their organisation, and the server checks this rule on every request” is clear enough to design, implement, and verify.
During testing, use the Top 10 to organise coverage without letting it limit the assessment. Business-logic abuse, privacy concerns, cloud configuration, technology-specific weaknesses, and risks unique to the organisation may fall between or across categories.
What the Top 10 does not prove
There is no universal “OWASP Top 10 passed” certificate. A tool can test for some signs of injection or misconfiguration, but it may miss an unsafe approval process, a subtle permission flaw, or a recovery workflow that can be abused. The depth and context of the review matter as much as the category names.
OWASP describes the Top 10 as an awareness document. Teams that need detailed application requirements can use the OWASP Application Security Verification Standard. Teams planning hands-on testing can use the OWASP Web Security Testing Guide alongside technology-specific and business-specific test cases.
A practical action plan
- Know what needs protection. List important data, user roles, administrative functions, payment or recovery flows, and external integrations.
- Map relevant categories. Identify which Top 10 areas could affect each important feature and what a failure would mean to the organisation.
- Write clear requirements. Define permissions, validation, encryption, update ownership, logging, and recovery in terms that can be verified.
- Build security into change. Review important designs, dependencies, and configuration before release rather than waiting for an annual scan.
- Test beyond automation. Use tools for useful coverage, then manually review access control, workflows, authentication, and application-specific behaviour.
- Monitor and respond. Record significant events, create useful alerts, and make sure the organisation knows who investigates them.
- Retest after fixes and major changes. Confirm that remediation works and that new features have not reintroduced the same risk.
The value of the OWASP Top 10 is not memorising ten names. It is using those risks to make better decisions before, during, and after software is released.
J77Cyber application security principle