OWASP Top 10: What Every Developer Should Know About It

Web security can feel like an alphabet soup of acronyms: CVE, XSS, SSRF, etc. It's easy to get lost in the maze of terminology. Yet, among all these, one stands out as particularly crucial: OWASP.

Whether you're a seasoned software engineer who has seen the Tannhäuser Gate or are just starting your journey in security, you've probably encountered references to OWASP and its most famous project: the Top 10.

But what exactly is it? Is there just one definitive Top 10 list? How does it relate to other security standards? And perhaps most importantly, how can you actually use it to make your applications more secure?

In this deep dive, we'll cut through the confusion and explore the world of web application security through the lens of the OWASP Top 10. We'll unpack not just what it is, but why it matters and how it shapes the security landscape of modern web development.

No jargon, no complexity—just clear, practical insights into one of the most important security frameworks for building secure software products. Let's begin!

💡 NOTE: This is a reprint of an article that was originally published in Architecting Security newsletter.

First things first: What is OWASP?

Before we discuss the Top 10, let's clarify what OWASP actually is. It's a detail that many people get wrong, even in the tech industry.

OWASP (Open Web Application Security Project) is a global organization that unites individuals who are committed to making software safer. Think of it as a worldwide community where security experts and developers collaborate to help others build secure software.

Here's what makes OWASP special: it's a non-profit organization that shares all its knowledge freely. They create guides, tools, and resources that anyone can use to make their software more secure. The Top 10 is just one of their many projects.

There's one common mistake I often hear in meetings and conferences. People refer to the "OWASP methodology"—but that's not quite right. It's like saying "Toyota methodology" when you mean Lean or Kanban. OWASP isn't a methodology; it's an organization that creates security guidelines and tools.

Now that we're clear on what OWASP is, let's look at their most famous project: the OWASP Top 10.

So What is Top 10?

The OWASP Top 10 is exactly what it sounds like: a list of the ten biggest security problems that affect web applications today. But there's more to it than just a simple countdown.

You can think of it as a ranked list, where the position of each security problem shows how severe it is for a typical organisation.

For example, when you see "A1: Broken Access Control" at the top of the list, it means this issue typically causes more trouble than "A10: Server-Side Request Forgery" which sits at the bottom.

Here's where things get interesting: while the Top 10 talks about risks, it's not really a risk list. Why? Because risk always depends on context.

Let me give you a real-world example: imagine finding the same vulnerability, like Cross-Site Scripting, in two different places:

1. In an internal tool that only employees can access.
2. On your public website that thousands of customers use every day.

Same vulnerability, same severity, but very different risk levels. (The public website version is much more dangerous because it's exposed to more potential attackers and affects more users.)

Top 10 Evolves Over Time

The security landscape is always changing, and the Top 10 changes with it. Since its first release in 2003, the list has been regularly updated to reflect new security problems and changing security patterns.

Let me show you how this works with a real example:

• In the 2017 version, Cross-Site Scripting (XSS) was listed as a separate problem.
• But in the current 2021 version, XSS became part of a larger category called "A3: Injections."

Right now, we're using the 2021 version, which makes it 4 years old in 2025. Based on the past, we're likely to see a new update this year (work is being done as you read this).

How is the Top 10 Created?

The process of updating the Top 10 is quite interesting. Here's how it works:

• First, the security community provides real-world data about vulnerabilities they find in their day-to-day work.
• Then, OWASP selects the 8 most common problems from this data.
• Finally, the community votes through an open survey to add 2 more issues.

You might wonder: Why not just pick the top 10 most common issues? Well, even with data from over 200,000 vulnerabilities (that's what they had for the 2021 version), some important problems might not show up often enough in the statistics.

So think of the community survey as a safety net. It helps catch new or emerging security threats that might not yet show up in the data but could be major problems in the future.

There is no one Top 10 list

The Top 10 tries to reflect reality in most cases, but different types of applications face different security challenges. For instance:

• A PHP application might face different security issues than a Ruby on Rails application.
• Different development teams tend to make different types of security mistakes.

This is why the Top 10 is skewed towards enterprise-level technology stacks (that’s where the data is coming from), and it’s also why you can create custom Top 10 lists.

Indeed, OWASP itself has created additional Top 10 lists for different needs. Examples include:

• OWASP Top 10 for APIs
• OWASP Top 10 for Serverless Applications
• OWASP Top 10 for Large Language Models (like ChatGPT)

Think of these specialised lists as focused security guidelines for specific types of applications. While the main Top 10 works as a good general benchmark for a typical web application, these specialised lists can help you focus on security issues most relevant to your specific domain.

From Awareness Tool to Industry Standard?

The OWASP Top 10 has an interesting story. It started as a simple way to help developers and managers understand security vulnerabilities affecting web applications. But over time, it became something bigger—many organisations now treat it as an industry standard.

Here's the catch, though: the Top 10 isn't meant to be a complete security standard. Even its creators are clear about this. When organisations need a proper security standard, OWASP itself recommends using the Application Security Verification Standard (ASVS) instead:

The creators also suggest that organizations should:

• Use ASVS for detailed security requirements.
• Build a complete security program using the Software Assurance Maturity Model (SAMM).

By the way, we will cover both of them in the future. Stay tuned!

Top 10 2021: The List Itself

We've talked a lot about what the Top 10 is, but let's get to the heart of it: what are these top security problems? Here's the current list from 2021, with plain English explanations of each:

1. Broken Access Control involves managing who can access what in your application. A good example is when users can view other users' private data simply by changing numbers in the URL. This is known as Insecure Direct Object Reference and is one of the most dangerous and common vulnerabilities in web applications.
2. Cryptographic Failures cover problems with how applications protect sensitive data. A classic example is when applications use outdated methods like MD5 or SHA-1 to store user passwords. Yes, there are much better ways to do that!
3. Injections happen when applications don't properly check what users type in. The well-known Cross-Site Scripting (XSS) falls into this category, allowing attackers to inject and run malicious JavaScript code on your website. It's worth noting that this particular problem has been haunting web applications for over 20 years and still persists.
4. Insecure Design refers to security flaws that exist in the basic design of applications. These problems run deeper than simple coding mistakes—think of a banking app that doesn't properly verify fund transfers. This is about fundamental design flaws rather than bugs at the implementation layer.
5. Security Misconfiguration occurs when security settings aren't set up correctly. Often, these are just default settings that nobody changed. These problems affect both applications and their infrastructure, such as when security headers are misconfigured or missing entirely.
6. Vulnerable and Outdated Components—a fascinating category that doesn't directly involve application code but rather the libraries that applications use. This problem can affect everything: front-end, back-end, and even the infrastructure serving them.
7. Identification and Authentication Failures is a broad category that involves problems with how users prove who they are. In extreme cases, vulnerabilities in this category can have truly catastrophic consequences, such as allowing attackers to bypass login completely.
8. Software and Data Integrity Failures involve problems with keeping code and data safe from tampering. A common example is when applications load external scripts from CDNs without verifying their integrity, potentially allowing attackers to inject malicious code.
9. Security Logging and Monitoring Failures refer to the issue of not maintaining proper records of activities within your application. A typical example is when applications fail to detect and block automated attacks, leaving them vulnerable to sustained malicious activity.
10. Server-Side Request Forgery (SSRF) is the only stand-alone vulnerability on the list, rather than a broad category. It occurs when attackers can make your server send requests it shouldn't, potentially exposing internal systems to attacks from outside world.

Here's something crucial to understand: while earlier versions of the Top 10 focused on specific vulnerabilities, the 2021 version mostly deals with broader categories of problems (except for SSRF at number 10).

This makes the list more comprehensive but also makes it impossible to definitively say an application is "free from OWASP Top 10 problems" because each category contains many specific vulnerabilities. Some categories, like Insecure Design, are so broad that they're almost philosophical in nature. Authors seem to agree:

Internal Structure

When we look inside, we'll see that each position from the Top 10 list has a broader description that contains the following sections:

1. A brief summary of the problem.
2. A broader, but not too broad, description of the given problem (for example, a short list of situations that can lead to the application being vulnerable).
3. A concise description of how to prevent the given problem.
4. Several examples of typical attacks (i.e., exploitation of vulnerabilities) in the form of scenarios.
5. References, most often to other OWASP projects such as the previously mentioned ASVS, but also to Cheat Sheets Series or Proactive Controls.
6. And finally, a list of CWEs that are part of the given problem class.

And you might wonder: What is CWE? CWE (Common Weakness Enumeration) is a separate project from the MITRE organization, whose authors set themselves the goal of enumerating all specific, individual weaknesses that can occur in software.

Are There Any Alternatives?

We’ve covered the most important aspects of the OWASP Top 10, and perhaps now you're wondering, "Are there any alternatives?" Of course! There are definitely similar non-OWASP lists.

A good example is the HackerOne Top 10, which is a Top 10 created by the world's largest Bug Bounty platform, through which almost 200,000 reports of actual vulnerabilities pass annually (along with probably the same amount of false positives…).

Another well-known market list of common security problems affecting all kinds of software is the CWE Top 25. As I mentioned earlier, a significant advantage of CWE is its attention to the level of abstraction. Each weakness listed in the CWE Top 25 is a specific issue, unlike the OWASP Top 10, which represents a class of problems. On the other hand, a downside is that it groups all weaknesses together regardless of application type.

For example, in the latest CWE Top 25 (which also changes over time), you’ll find Use-After-Free. This is fine, but this weakness is typical for applications written in low-level languages such as C++ (e.g., browsers). So, if you’re working in web development—and that's where most work is done—then Use-After-Free doesn't really concern you because it doesn't affect you.

Next Steps

Now that you know what the Top 10 is, you probably have a question forming in your head: How can it be used? I'll give you two directions:

1. The Top 10 works great in building basic awareness about web application security problems among development teams. Here I talk the talk and walk the walk—OWASP Top 10 is one of the foundations of my own training programmes with which I have had great success in Poland.
2. The Top 10 can be used in early development phases, e.g., as an attack library in Threat Modeling sessions and/or as a checklist baseline during the implementation phase in the Secure Code Review process. There are better tools for both these areas, but the Top 10 can definitely be a starting point there.

That's all for today folks. Best regards, and see you next week!

---

P.S. If you found this article useful, please pay the fee by sharing it with someone you know will also benefit from it. Thank you very much! 🙏