OWASP Top 10, Explained: What a Website Vulnerability

By Md Danish, Founder and Editor in Chief

Every few months a fresh data breach makes the news, and the write-up almost always ends the same way: attackers exploited a known, ordinary weakness. Not some movie-grade zero-day, just a login that trusted the wrong input, or an admin page that forgot to ask who you were. The security industry has a name for that short list of ordinary weaknesses. It is called the OWASP Top 10, and it is the closest thing web security has to a shared checklist.

I spent time this year building a small vulnerability scanner in Python that walks a website through that exact list, so this is a practitioner tour rather than a textbook one. The goal here is simple: explain what each risk really means, and what an automated scanner can honestly tell you about it.

Why the OWASP Top 10 still matters

The OWASP Top 10 is maintained by the Open Worldwide Application Security Project, a non-profit that studies real breach data and ranks the ten categories of web risk that show up most often. It is not a law and it is not complete. What it is, is a common language. When a security report says a site has an A03 problem, every practitioner in the room knows that means injection, without another word. That shared shorthand is why the list has outlived a dozen security fads.

The current edition groups risks into ten families, from A01 to A10. You do not need to memorise the numbers. You need to understand the shape of each problem, because the shape is what a scanner looks for.

A01: Broken Access Control

This one sits at the top of the list for a reason. Broken access control means the site lets someone reach a page or an action they should never be allowed to reach. The classic example is an admin dashboard that opens for anyone who simply types the right address, with no login in the way. Change a number in a URL and suddenly you are reading another customer’s order. That is broken access control too.

A scanner tests this by asking for sensitive paths directly and watching the answer. If a page that should demand a login returns the real content instead of a login form, that is a finding. It is a blunt test, but it catches the most embarrassing failures, the ones where there was no lock on the door at all.

A03: Injection, the classic that refuses to die

Injection covers SQL injection and cross-site scripting, and it has been near the top of this list for over twenty years. The idea is always the same. The application takes something a user typed and treats it as a command instead of as plain text. Type a crafted value into a search box and the database runs it as a query. Type a script tag into a comment and the next visitor’s browser runs it.

Each pattern has a formal identifier in the MITRE CWE catalogue, which is the reference engineers use to name a weakness precisely. A scanner probes for injection by sending a known test payload and reading the response. If the raw payload comes back reflected in the page, or the database coughs up an error, the door is open. The fix is old and reliable: never trust input, and keep data separate from commands.

A05: Security Misconfiguration and the quiet leaks

Not every weakness is a dramatic break-in. Many are just a server left in a careless state. Missing security headers that would tell a browser to behave safely. A version banner that announces the exact software running, handing an attacker a shopping list of known exploits. A configuration file or a backup left sitting in a public folder. None of these is an exploit on its own, but together they lower the wall.

This is where an automated scan earns its keep. Reading response headers, spotting an exposed file, and flagging a leaked version string are exactly the tedious, repetitive checks a tool does faster and more reliably than a person. Bodies like the US National Institute of Standards and Technology publish hardening guidance that turns these findings into a concrete to-do list.

A10 and the rest: SSRF, integrity, and logging

The lower half of the list is less famous but not less serious. Server-side request forgery, A10, is when you can trick the server itself into fetching a web address you choose, which can expose internal systems that were never meant to face the public. Software and data integrity failures cover trusting code or updates that were never verified. And the quiet one, security logging and monitoring failures, is about not noticing an attack while it happens.

That last category is worth pausing on, because it exposes the limit of any scanner. Whether a site keeps good logs and watches them is something you cannot see from outside. A tool that pretends to test it is lying to you. An honest report marks it as a manual review item and moves on.

What a scanner can and cannot tell you

Here is the part the marketing tends to skip. An automated scan is very good at the loud, obvious, external failures: the open admin page, the reflected payload, the missing header, the leaked file. Those are real risks and finding them fast has genuine value. Interactive labs like the PortSwigger Web Security Academy are built around practising exactly these attacks by hand, which is how you learn what a tool is really checking.

What a scanner cannot do is understand your business logic. It does not know that this user should not be able to approve their own refund, or that this workflow skips a step it should not. Those are design flaws, and finding them still takes a human who understands the application. The right way to read a scan is as a first pass that clears the obvious ground so the expensive human review can focus on the subtle problems.

How to actually use this list

If you run a website, you do not need to become a security researcher to benefit from the OWASP Top 10. Treat it as a checklist you revisit. Make sure every sensitive page enforces a login. Make sure user input is never trusted as a command. Turn on the security headers. Hide your version banners. Keep secrets out of public folders. Watch your logs. None of that is exotic, and most of it is free.

The uncomfortable lesson from years of breach reports is that the exotic attack is rare. The ordinary one, the one on this list, is what actually gets people. A scanner helps you find the ordinary problems before someone else does, and the Top 10 is the map it follows. Start there, fix what it finds, and you have already closed the doors most attackers walk through.

Sources: OWASP Top 10, MITRE CWE, NIST Cybersecurity, PortSwigger Web Security Academy.

OWASP Top 10, Explained: What a Website Vulnerability Scanner Actually Checks