Every web application your company publishes is at once a business asset and an entry point. The OWASP Top 10 is the world's most used map for closing those doors: a prioritized list of the ten most critical application security risks, maintained by a global community and adopted as the de facto reference by development teams, auditors and regulators. Understanding each of these risks, and what to do about them, is the starting point of any serious application security (AppSec) program.
What the OWASP Top 10 is and why it became the reference
OWASP (Open Worldwide Application Security Project) is a nonprofit foundation dedicated to improving software security. Its best-known project, the Top 10, is an awareness document that consolidates the ten most serious risks for web applications. The document's strength comes from its methodology: OWASP combines test data collected from hundreds of organizations, covering hundreds of thousands of applications, with a community survey that captures emerging risks still underrepresented in the data. The result is a list that reflects both what is already happening and what is about to happen.
This combination of rigor and openness made the Top 10 get incorporated into standards and contracts worldwide. PCI DSS, industry standards and development contract clauses often explicitly require the application to be free of OWASP Top 10 risks. For a product team, mastering the list stopped being a differentiator and became a basic requirement for entry into the B2B market.
The most recent edition is the OWASP Top 10:2021. It brought an important conceptual shift from 2017: the categories came to be organized more by root cause than by symptom. Instead of listing only what the attacker exploits, the 2021 list asks why the flaw exists, which makes mitigation more structural and durable.
The 10 risks of the 2021 edition, one by one
Below, each category with what it represents and how to reduce the risk in practice. Further down is a summary table with the code, name and key mitigation of each item.
A01:2021 - Broken Access Control
Broken access control means a user can do something they shouldn't: access another account's data, perform administrator actions or bypass role restrictions. The classic case is IDOR (Insecure Direct Object Reference), where changing an identifier in the URL (from /invoice/1001 to /invoice/1002) hands over another customer's document. In the 2021 data, this was the category with the most occurrences, present in 94% of tested applications, and that's why it jumped to first place. To mitigate, deny access by default (deny by default), enforce authorization on the server on every request (never trusting the front end), centralize the permission logic and enforce ownership verification of the resource before any read or write.
A02:2021 - Cryptographic Failures
Previously called Sensitive Data Exposure, this category was renamed to point to the cause rather than the effect: the root problem is usually a cryptographic failure. Sensitive data traveling without TLS, passwords stored with weak or unsalted hashes, use of obsolete algorithms (MD5, SHA-1, DES) and poorly managed keys all fall here. Mitigation involves classifying sensitive data, encrypting everything in transit (TLS 1.2 or higher) and at rest, using modern algorithms and password derivation functions built for this purpose (Argon2, bcrypt, scrypt), and treating key management as a formal process, not a detail.
A03:2021 - Injection
Injection happens when untrusted data is interpreted as a command by an interpreter. The best-known form is SQL injection, but the category also covers operating system commands, LDAP, ORM and template expressions. In the 2021 edition, Cross-Site Scripting (XSS) was absorbed into this category, since it's technically script injection into the victim's browser. The defenses are well established: use parameterized queries (prepared statements), validate input with allowlists, escape output according to context and prefer secure ORMs and APIs. We go deeper into the two main vectors in our guides to SQL Injection and XSS (Cross-Site Scripting).
A04:2021 - Insecure Design
A new category in 2021 and one of the most important conceptually. Insecure Design is an architecture flaw, not an implementation flaw: the system was designed without considering threats, and no perfect implementation fixes that. One example is a password recovery flow based on security questions anyone can look up. The defense is to shift security left: adopt threat modeling from the design stage, use secure design patterns and trusted component libraries, and write security requirements alongside functional requirements.
A05:2021 - Security Misconfiguration
Security misconfiguration is the most pervasive day-to-day category: servers with default accounts and passwords, unnecessary features enabled, error messages that leak stack traces, overly open cloud permissions (public buckets) and missing security headers. In 2021, the old XXE (XML External Entities) was consolidated here, since it too is a parser configuration issue. Mitigation is to harden all environments in a repeatable, automated way, remove what isn't used, keep development, staging and production environments consistent and review configurations continuously.
A06:2021 - Vulnerable and Outdated Components
Modern applications are assembled from dozens or hundreds of third-party libraries, and each one may carry a known vulnerability. Historic incidents like Log4Shell showed the destructive potential of a single widely used vulnerable component. The defense is to build a software inventory (SBOM), adopt Software Composition Analysis (SCA) in the pipeline to alert on CVEs in dependencies, remove unused libraries and maintain an agile update process, obtaining components only from official sources.
A07:2021 - Identification and Authentication Failures
Previously called Broken Authentication, it covers flaws that allow taking over another user's identity: lack of protection against brute force and credential stuffing, sessions that don't expire, predictable session identifiers and the absence of multi-factor authentication (MFA). To mitigate, implement MFA, block common and leaked passwords, limit login attempts, generate session identifiers securely on the server and invalidate sessions properly on logout and on password change.
A08:2021 - Software and Data Integrity Failures
Another new category in 2021, focused on trusting code or data without verifying its integrity. It includes insecure CI/CD pipelines, automatic updates without signature verification and insecure deserialization of data, as well as software supply chain attacks. Mitigation involves using digital signatures to verify the origin of software and updates, ensuring dependencies come from trusted repositories, protecting the build pipeline against tampering and reviewing code and configuration changes.
A09:2021 - Security Logging and Monitoring Failures
Without adequate logging and monitoring, an attack can go unnoticed for months. This category addresses the inability to detect, escalate and respond to active incidents: unlogged security events, logs without useful detail, absence of alerts and lack of integration with detection. The defense is to log relevant events (login, access failures, high-value transactions) with sufficient context, ensure logs are protected against tampering, centralize them and connect them to an incident response process with actionable alerts.
A10:2021 - Server-Side Request Forgery (SSRF)
SSRF entered the Top 10 in 2021, driven by the community survey. It occurs when the application fetches a resource from a user-supplied URL without validating the destination, allowing the attacker to force the server to make requests to internal systems, cloud metadata or services that shouldn't be reachable from outside. Mitigation involves validating and allowlisting destinations, segmenting the network to isolate internal resources, disabling redirects and never sending the server's raw response back to the client.
OWASP Top 10:2021 summary table
| Code | Name | Key mitigation |
|---|---|---|
| A01 | Broken Access Control | Deny by default; authorize on the server on every request |
| A02 | Cryptographic Failures | TLS, encryption at rest and strong password hashing (Argon2/bcrypt) |
| A03 | Injection (SQLi/XSS) | Parameterized queries, validation and contextual output escaping |
| A04 | Insecure Design | Threat modeling and secure design patterns (shift left) |
| A05 | Security Misconfiguration | Automated hardening and removal of unnecessary features |
| A06 | Vulnerable and Outdated Components | SBOM, SCA in the pipeline and agile dependency updates |
| A07 | Identification and Authentication Failures | MFA, anti-brute-force and secure session management |
| A08 | Software and Data Integrity Failures | Digital signatures and protection of the CI/CD pipeline |
| A09 | Security Logging and Monitoring Failures | Security event logging, centralization and actionable alerts |
| A10 | Server-Side Request Forgery (SSRF) | Destination allowlisting and network segmentation |
What changed from 2017 to 2021
Anyone familiar with the previous edition will notice three new entries and several reorganizations. The brand-new categories are A04 Insecure Design, A08 Software and Data Integrity Failures and A10 SSRF, reflecting the market's maturity in discussing architecture, supply chain and attacks on internal services. Broken Access Control rose from fifth to first place. Cross-Site Scripting stopped being its own category and was absorbed into A03 Injection. The old A04 XML External Entities (XXE) became part of A05 Security Misconfiguration. And, as already mentioned, several names were adjusted to point to the root cause, as with Sensitive Data Exposure becoming Cryptographic Failures.
The Top 10 is not a complete checklist
It's worth repeating a point OWASP itself is keen to stress: the Top 10 is an awareness document, not a certification standard nor an exhaustive list. There are important risks that don't appear in it, and treating the list as the ceiling of security leaves entire classes of vulnerability uncovered. For a comprehensive verification, the reference is the OWASP ASVS (Application Security Verification Standard), which details hundreds of verifiable requirements by criticality level. The Top 10 is the floor where every program starts; the ASVS is where a mature program arrives. For applications that expose integration interfaces, it's also worth consulting our dedicated guide to API security, which has its own specific Top 10.
How the Top 10 connects to SAST, DAST and pentest
No single technique covers all ten risks. Best practice is to combine them across the development cycle. Static analysis (SAST) reads the source code and is strong at finding injection patterns, hardcoded secrets and insecure deserialization even before the application runs. Dynamic analysis (DAST) tests the running application and covers misconfiguration, missing headers and authentication flaws that only manifest in a real environment. Composition analysis (SCA) directly targets A06, alerting on vulnerable components. We detail the differences and when to use each approach in the SAST and DAST guide.
What no automated tool does well is understand business logic. Risks like A01 Broken Access Control and A04 Insecure Design depend on understanding the application's rules, who should be able to do what, and therefore require a human tester's eye. That's where manual pentesting comes in: a specialist who reproduces the reasoning of a real attacker, chains flaws and finds the paths scanners can't see. An effective AppSec program uses tools for scale and coverage, and pentesting for depth in logic.
How Decripte handles the OWASP Top 10
Decripte is a B2B cybersecurity company that structures application security programs end to end, from a startup's first application to portfolios with hundreds of systems in large operations. We integrate SAST, SCA and DAST into your CI/CD pipeline to stop the automatable risks while still in development, and we conduct manual pentesting guided by the OWASP Top 10 and the ASVS to cover the business logic tools can't reach. The result is delivered with risk-prioritized remediation and revalidation, so that each fix is confirmed and not merely logged.
Want to map where your application is exposed to the ten risks? Start free through our Intelligence Center or explore the plans for an AppSec program tailored to the size of your operation.
References
- OWASP Top 10:2021 - owasp.org/Top10
- OWASP Application Security Verification Standard (ASVS) - owasp.org
- OWASP API Security Top 10 - owasp.org/API-Security
- MITRE Common Weakness Enumeration (CWE) - cwe.mitre.org
- NIST Secure Software Development Framework (SSDF), SP 800-218 - csrc.nist.gov