OWASP Top 10 Explained
The OWASP Top 10 is a ranked awareness document of the most critical web application security risks. It is not a checklist and it is not a standard. Broken access control has been at number one because it is the most common and the least detectable by scanners, which is exactly why manual testing still matters.
The categories, and what they mean in practice
Broken access control
The application checks that you are logged in but not that the thing you asked for belongs to you. Change an id in a request and read another user's data.
No scanner reliably finds this because it requires knowing what should be allowed. Test it with two accounts: capture a request as user A, replay it as user B. This single technique produces more high severity findings than anything else on this list.
Cryptographic failures
Sensitive data in transit or at rest without adequate protection. Plaintext transmission, weak hashing for passwords, hardcoded keys, secrets in a repository. Look at what the application stores and how, not just whether HTTPS is on.
Injection
SQL, command, LDAP, template. Input becomes part of a command instead of staying data. Full walkthrough in the SQL injection guide. Cross site scripting sits in this family too, covered in XSS explained.
Insecure design
The category people skip because it is not a bug you can fire a payload at. It covers flaws in the logic itself: a password reset that can be replayed, a checkout that accepts negative quantities, a refund flow with no limit. Found by thinking about the workflow, never by a tool.
Security misconfiguration
Default credentials, verbose errors, directory listing, unnecessary features enabled, missing hardening. Cheap to find and cheap to fix, which is why it is embarrassing when it turns up in a report.
Vulnerable and outdated components
Known CVEs in libraries you shipped. Easy to detect, tedious to fix, and the most common cause of an incident that could have been avoided entirely.
Identification and authentication failures
Credential stuffing viability, weak session handling, tokens that do not expire, password reset that can be hijacked, missing rate limiting on login and OTP separately. Test both endpoints, not just the password one.
Software and data integrity failures
Trusting code or data from a source you do not control. Unsigned updates, CI pipelines that pull unpinned dependencies, insecure deserialisation.
Security logging and monitoring failures
The one that decides whether an incident lasts an hour or a quarter. If nothing logs the attack, nobody detects it. Worth understanding from the defensive side too, see what a SOC analyst actually does.
Server side request forgery
The application fetches a URL you control, reaching internal systems you cannot. In cloud environments it escalates to credential theft through the metadata service. Full detail in SSRF explained.
How to actually use this list
| Use it as | Do not use it as |
|---|---|
| A coverage reminder while testing | A compliance checklist |
| A shared vocabulary in reports | Proof the app is secure |
| A training curriculum order | An exhaustive vulnerability list |
An application can pass every category and still be trivially compromised through business logic nobody modelled. The list is a floor, not a ceiling.
The order to learn them in
- Injection, because the mechanics generalise to everything else
- Cross site scripting, because context handling teaches you to read responses carefully
- Broken access control, because it produces the most real findings
- Authentication failures, because every application has a login
- SSRF, because cloud escalation makes it high impact
- Insecure design, last, because it requires judgement you build from the first five
That sequence is how the VAPT syllabus is ordered.
Practise this
Exploit each category at least three times before moving on. Reading a definition and exploiting the thing produce completely different recall. Free web challenges on Hacklido.
Frequently asked questions
Is the OWASP Top 10 a standard?
No. It is an awareness document listing the most critical risks. Standards like ASVS and the testing guide WSTG are what you actually test against.
Why is broken access control ranked first?
Because it is both the most common and the hardest for automated tools to find, since a scanner cannot know what a given user should be allowed to see.
Can a scanner find all OWASP Top 10 issues?
No. Broken access control and insecure design in particular require a human who understands the application's intended behaviour.
Is the OWASP Top 10 enough for compliance?
It is usually referenced by compliance frameworks but is not sufficient on its own. Indian regulatory testing under CERT-In expects evidence of manual testing beyond a checklist.
Where should a beginner start?
Injection first, then XSS, then broken access control. The first two teach mechanics and the third produces the most real findings.
See the full VAPT syllabus
Live instructor led training, hands on labs and a verifiable certificate. Or start free on Hacklido before paying anyone.
See the full VAPT syllabus