unicornAll work
All theoryWeb security

OWASP Top 10

The map of where web apps break most often — the shared vocabulary of web security.

In a nutshell The OWASP Top 10 is a regularly updated list of the ten most critical web-application security risks, agreed by the industry. It isn't a law or a full checklist — it's the map of "where web apps break most often," and the shared vocabulary every web pentester and developer uses.

What OWASP is and why the list exists

OWASP (the Open Worldwide Application Security Project) is a non-profit publishing free security knowledge. Its most famous output, the Top 10, distills years of real breach data into ten categories. Developers use it as a "don't do these" list; testers as a "check for these" list.

Analogy — a building inspector's checklist. An inspector doesn't test the house at random; they carry a list of the ten things that most often go wrong — wiring, damp, foundations. The Top 10 is that list for web apps.

The categories (2021 edition)

# Category In plain words
A01 Broken Access Control you reach things you shouldn't (others' data, admin)
A02 Cryptographic Failures secrets sent/stored badly (no HTTPS, plaintext passwords)
A03 Injection untrusted input treated as code — SQLi, command, XSS
A04 Insecure Design the flaw is in the plan, not a bug
A05 Security Misconfiguration defaults on, debug pages exposed
A06 Vulnerable & Outdated Components a library/service with a known bug
A07 Identification & Auth Failures weak login, bad session handling
A08 Software & Data Integrity Failures trusting tamperable updates/data
A09 Logging & Monitoring Failures attacks go unnoticed
A10 Server-Side Request Forgery tricking the server into making requests

The one lesson under all ten

Most of the list reduces to one habit — never trust the client. The browser shows only your data, but the server must check every request, because the client is fully under the attacker's control:

Browser Server any request the attacker controls everything on the left
Whatever the client sends can be forged. Every rule must be enforced server-side.

How to actually use it

As a tester

  • it's your enumeration order
  • walk each category against the app
  • most findings slot into one bucket

As a developer

  • it's a design-review checklist
  • before shipping, ask "handled?" per item
  • catch classes of bug, not one bug

The one that dominates — Broken Access Control

A01 tops the list because it's everywhere and easy to get wrong: the app shows you only your own data, but the server doesn't check when you ask for someone else's.

GET /account?id=123   → your account   (fine)
GET /account?id=124   → someone else's  ← Broken Access Control (an IDOR)
Where to go next The Top 10 is the index; the chapters are here — SQL injection, XSS and Command injection under A03; Authentication & sessions under A07; File upload & inclusion touching several.
All theory