The OWASP Top 10 is the best known reference in web application security. It is published by the Open Worldwide Application Security Project, a non-profit community of security practitioners from around the world, and it summarizes the ten most serious categories of risk for web applications.1 The current edition was released in 2021 and groups risks into broad classes rather than individual bugs. Each class covers many specific weaknesses that share a root cause. That grouping is the point: it gives development teams, testers, and the executives who commission software a shared vocabulary for the problems that cause the most real damage.
For a regulated company, the list matters because it maps closely to how breaches actually happen. Broken access control, injection, and misconfiguration sit behind a large share of the incidents that lead to data exposure, regulatory reporting, and customer harm. Frameworks such as ISO/IEC 27001:2022, SOC 2, NIS2, and DORA all expect you to manage application risk in a structured way, and the OWASP Top 10 is the most widely accepted starting point for doing that on the web layer. It is not a law and not a certification. It is a baseline that tells you where to look first.1
This is part of our application security overview. We test for and fix these risks through application and cloud security and offensive security.
What OWASP is and why the list is the industry reference
OWASP is an open community that publishes tools, guides, and standards for software security free of charge. Anyone can read, use, or contribute to its projects. That openness is why its work spread so widely: there is no license fee and no vendor agenda behind it. The Top 10 began as an awareness document and became the default way the industry talks about web risk.
The list is built from data and expert review. OWASP collects vulnerability data contributed by testing firms and tooling vendors across many applications, then combines that evidence with a practitioner survey to capture risks the data alone would miss.1 Categories are ranked by a mix of how often they appear, how exploitable they are, and how much damage they cause. This is why it is treated as a reference rather than one company's opinion. Contracts, security questionnaires, and procurement requirements routinely point to it, so understanding it is now part of doing business in regulated sectors.
The ten 2021 categories, explained
The 2021 edition contains ten categories. Below, each one is described in plain terms with a concrete example and the core defense, so you can connect the abstract name to something an attacker would actually do.1
| Category | What it means and an example | Primary defense |
|---|---|---|
| A01 Broken Access Control | A user reaches data or actions that are not theirs. Example: changing the ID in a URL from /invoice/1001 to /invoice/1002 and seeing another customer's invoice. | Enforce authorization on the server for every request. Deny by default and check ownership on each object, not just at login. |
| A02 Cryptographic Failures | Sensitive data is not properly protected in transit or at rest. Example: passwords stored as unsalted hashes, or an API serving customer data over plain HTTP. | Encrypt data in transit and at rest with current algorithms. Use strong, salted password hashing such as bcrypt or Argon2. |
| A03 Injection | Untrusted input is treated as code or part of a query. Example: a login form where typing ' OR '1'='1 bypasses the SQL check and returns all users. | Use parameterized queries and prepared statements. Validate and escape input. Never build queries by string concatenation. |
| A04 Insecure Design | The architecture itself is flawed, before any coding mistake. Example: a password reset flow that lets anyone reset an account with only a public email address. | Threat model during design. Build security requirements and abuse cases into the feature before code is written. |
| A05 Security Misconfiguration | Default, incomplete, or careless configuration exposes the system. Example: a cloud storage bucket left public, or verbose error pages that leak stack traces. | Harden configuration to a known baseline. Disable defaults, close unused features, and review settings as part of deployment. |
| A06 Vulnerable and Outdated Components | Using libraries, frameworks, or runtimes with known vulnerabilities. Example: an old version of a logging library with a published remote code execution flaw. | Track every dependency, monitor advisories, and patch promptly. Maintain a software bill of materials. |
| A07 Identification and Authentication Failures | Weak handling of login, sessions, and credentials. Example: no rate limiting on login, so an attacker can try millions of passwords against an account. | Enforce multi-factor authentication, rate limiting, and secure session handling. Block weak and breached passwords. |
| A08 Software and Data Integrity Failures | Code or data is accepted from an untrusted source without verification. Example: a build pipeline that pulls an update from a server an attacker has compromised. | Verify signatures and integrity of updates, packages, and CI/CD inputs. Secure the build and deployment pipeline. |
| A09 Security Logging and Monitoring Failures | An attack goes unnoticed because there are no logs or alerts. Example: an attacker probes the app for weeks and nothing is recorded, so the breach is found only when data appears for sale. | Log security-relevant events, retain them, and alert on suspicious activity. Feed logs into monitoring that someone watches. |
| A10 Server-Side Request Forgery (SSRF) | The application is tricked into making a request to a destination the attacker chooses. Example: an image-fetch feature pointed at an internal cloud metadata service to steal credentials. | Validate and restrict outbound destinations. Use allowlists, block internal address ranges, and isolate network access. |
Why these categories cause real breaches
The categories are not ranked by how clever they are. They are ranked by impact in the real world. Broken access control moved to the top of the 2021 list because it appeared in more tested applications than any other category.1 It is also the kind of flaw that automated tools rarely catch, because deciding whether a user should see a given record requires understanding the business, not just the code.
Injection has been near the top for over a decade. A single unparameterized query can expose an entire database. Cryptographic failures cause direct regulatory exposure, because under GDPR the difference between encrypted and unencrypted personal data can decide whether a breach is reportable and how severe the consequences are. Vulnerable components are the route many ransomware and supply-chain attacks take, since one unpatched library can open a path into otherwise solid code. These are not theoretical. They are the mechanisms behind the breaches that make the news.
The OWASP Top 10 is ranked by what actually breaks production systems, not by what is hard to exploit.
How the list is used in practice
In practice, the Top 10 is used as a baseline, not a finish line. Development teams use it as a checklist of classes to design against. Testers use it to structure the early phase of an assessment and to make sure no major category is skipped. Procurement teams use it as a question to vendors: tell us how your application addresses each of the ten. Used this way, it raises the floor across an organization and gives non-specialists a way to ask sensible questions.
The crucial point is what the list does not do. It does not enumerate every vulnerability, and it does not guarantee security when every box is ticked. Two applications can both address all ten categories and still differ enormously in how secure they are, because the hard flaws live in business logic, in how features interact, and in the specific context of each system. The list tells you the common classes. It cannot tell you about the unique mistake your team made last sprint. For more on why this distinction matters, see pentest vs scan.
The link to testing and secure development
The Top 10 connects directly to how you build and how you test. On the build side, it pairs with secure development practices such as those in the NIST Secure Software Development Framework, which expects security to be considered from design onward rather than bolted on at the end.2 A team that knows the ten classes can design against them, choose safe defaults, and avoid whole categories of flaw before writing code. This shift-left thinking is the core of DevSecOps.
On the testing side, the list shapes the early stages of a web application penetration test. A tester confirms the common categories are handled, then spends the bulk of the engagement on the deeper flaws that no list can predict. For applications that lean on APIs, the web Top 10 is not enough on its own; OWASP maintains a separate API Security Top 10, covered in our guide to API security testing. The steps below show how the categories fit into a working development cycle rather than a one-off review.
- 01Design against the classesThreat model each significant feature before coding. Treat insecure design (A04) as a first-class risk and define security requirements up front.
- 02Validate input and enforce accessTreat every external input as untrusted to address injection (A03), and check authorization on the server for every action to address broken access control (A01).
- 03Manage your componentsTrack every dependency and patch known vulnerabilities promptly to address vulnerable components (A06) and integrity failures (A08).
- 04Harden and monitorConfigure environments to a hardened baseline (A05) and log security events with alerting (A09), so an attack is caught early.
- 05Test with humans, not just toolsCombine automated scanning with manual penetration testing to find the access-control and logic flaws that tools miss.
How the Top 10 fits your compliance work
Regulated companies rarely adopt the OWASP Top 10 in isolation. It sits inside a wider control set. ISO/IEC 27001:2022 expects secure development and application risk management as part of an information security management system. SOC 2 reviews how you protect customer data, which includes the application layer. NIS2 and DORA both push regulated entities toward demonstrable, tested security rather than paper policies. In each case, being able to show that you design and test against the Top 10, and that you go beyond it with manual testing, is concrete evidence that your application security is real.
The list also helps you talk to auditors and customers in language they recognize. When a security questionnaire asks how you handle web application risk, pointing to a structured program built on the Top 10 plus regular penetration testing is a clear, credible answer. It shows you have a method, not just good intentions.
How Raptoric helps
We test web applications against the OWASP methodology and go past the baseline to find the access-control and logic flaws that scanners miss, through application and cloud security and offensive security. We also help development teams build security into the process from design through delivery, so the common classes are handled before testing begins. Book a scoping call.