HolyGhost logoHolyGhost
← cd ..
Learn

What Is the OWASP Top Ten? The Web's Most Famous Risk List

A beginner friendly tour of the OWASP Top Ten, the widely used list of the most critical web application security risks, and how its categories map to real attacks.

HolyGhost··6 min read

If you spend any time around web security, you will hear the phrase "OWASP Top Ten" within about five minutes. It is quoted in job interviews, security reports, and boardroom slides alike. For something so widely referenced, it is surprisingly simple: it is a list, refreshed every few years, of the ten kinds of web application weakness that hurt people the most. Think of it as the security world's shared shorthand for "the things that keep going wrong". This is a plain tour of what it is, and how each item connects to real attacks.

Who OWASP are, and what the list is for

OWASP stands for the Open Worldwide Application Security Project (it was originally the Open Web Application Security Project). It is a non profit community that produces free, openly available security resources, tools, and guidance. Nobody has to pay to use any of it, which is a big part of why its work spread so widely.

The Top Ten is their most famous output. It is an awareness document: a ranked list of the ten most critical web application security risks, written to give developers, testers, and managers a common starting point. Two things are worth understanding straight away.

  • It is not an exhaustive checklist. Ticking off all ten does not mean you are secure. It is a map of the biggest and most common danger areas, not the whole territory.
  • It is periodically updated. OWASP refreshes the list every few years as the web changes, with past editions in 2013, 2017, and 2021. The categories and their order shift between editions. The version described below is the widely adopted 2021 edition, which remains the common reference point, so treat the exact numbering as a snapshot rather than something permanent.

Why a shared list matters

The real value of the Top Ten is that it gives everyone the same language. When a tester says "this is an A03 injection issue" or a manager asks "how do we do on access control", they are pointing at the same well understood category. A shared vocabulary is quietly one of the most useful things in security, because it lets very different people talk about risk without talking past each other.

The ten categories, in plain terms

Here is the 2021 list, each explained in a sentence or two, with links to the deeper writeups on this site where they exist.

A01. Broken Access Control. Users managing to do things they should not be allowed to, like viewing someone else's account or reaching an admin page. This rose to the top spot because it is so common and so damaging. Access control is simply the rules about who can do what.

A02. Cryptographic Failures. Sensitive data left unprotected because encryption was missing, weak, or misconfigured. If you are shaky on the underlying ideas, start with what is encryption.

A03. Injection. Untrusted input being treated as commands. This famous family includes SQL injection, where input becomes a database query, and cross site scripting, where input becomes JavaScript in someone's browser.

A04. Insecure Design. Weaknesses baked in at the design stage, before a line of code is written, because the threats were never thought through. This is where threat modelling earns its keep.

A05. Security Misconfiguration. Insecure default settings, unnecessary features left switched on, or sloppy configuration. Often the easiest thing for an attacker to find and the easiest thing for a team to fix.

A06. Vulnerable and Outdated Components. Building on software with known holes, a dependency or library that has a public flaw and an available fix that nobody applied. Log4Shell is the textbook example, and it is why patching matters so much.

A07. Identification and Authentication Failures. Weak handling of logging in and sessions: guessable passwords, broken "forgot password" flows, sessions that never expire. Strong multifactor authentication addresses a lot of this.

A08. Software and Data Integrity Failures. Trusting code or data whose integrity was never verified, from tampered updates to insecure deserialization. The SolarWinds attack is the extreme version of this idea.

A09. Security Logging and Monitoring Failures. Not recording what happens, or not watching the records, so attacks go unnoticed for far too long. This is the gap a security operations centre exists to close.

A10. Server Side Request Forgery (SSRF). Tricking the server into fetching a web address the attacker chose, often to reach internal systems. We pull this one apart in SSRF and the cloud metadata endpoint.

Notice how they overlap with everything else

Almost every specific attack you read about slots into one of these buckets. That is the point. When you meet a new vulnerability, ask which Top Ten category it belongs to, and you instantly have a frame for what it is and why it matters. The list is a set of pigeonholes for the whole messy world of web weaknesses.

How to actually use it

The Top Ten is most useful as a prioritisation and awareness tool, not a certificate. A few sensible ways teams put it to work:

  • As a learning path. If you are new, working through the ten categories is a well signposted tour of what to understand first.
  • As a review lens. When designing or reviewing a feature, walk it against the ten and ask "could any of these apply here?" It is a lightweight cousin of full threat modelling.
  • As a shared language between developers, testers, and management, so everyone is pointing at the same risks.

Do not mistake the list for the whole job

Because it is famous, the Top Ten sometimes gets treated as a finish line: "we handled the Top Ten, so we are secure". It was never meant to be that. It is the ten most critical categories, a floor to build on, not a ceiling. Plenty of serious issues live outside it. Use it as a strong starting point, then keep going.

The takeaway

The OWASP Top Ten is a free, periodically updated list from the Open Worldwide Application Security Project naming the ten most critical web application security risks, from broken access control and injection to vulnerable components and server side request forgery. Its greatest strength is giving everyone a shared language and a sensible set of priorities. Use it as a learning path, a review lens, and a common vocabulary, but remember it is a well drawn map of the biggest dangers, not the entire territory. Handle the ten, and then keep looking.