OWASP Top 10 Explained Simply
The OWASP Top 10 is a periodically updated list of the most critical web application security risks, maintained by the Open Worldwide Application Security Project. It is the single most referenced framework in web application testing, and it is written for practitioners first, which makes it denser than it needs to be for anyone reading a report rather than writing the code.
The categories, in plain language
- Broken access control. The application lets a user do or see something they should not be permitted to, usually because a permission check is missing or incomplete somewhere.
- Cryptographic failures. Sensitive data is stored or transmitted without adequate protection, weak encryption, or none at all.
- Injection. Untrusted input reaches an interpreter, a database, a command shell, without being properly separated from that interpreter's own syntax. SQL injection is the best-known example; see our dedicated piece on SQL injection.
- Insecure design. The flaw is not a bug in the implementation, it is a gap in how the feature was designed in the first place.
- Security misconfiguration. Default credentials, unnecessary features left enabled, overly permissive settings, the kind of thing that exists because nobody hardened it rather than because anyone made an active mistake.
- Vulnerable and outdated components. Using a library or framework version with a known, published weakness. See our piece on supply chain security.
- Identification and authentication failures. Weaknesses in how the application confirms who a user actually is.
- Software and data integrity failures. Trusting a piece of software or data without verifying it has not been tampered with, a category that includes a lot of supply chain and CI/CD risk.
- Security logging and monitoring failures. Not the same as the audit trail we write about elsewhere, this is about whether an organization would even notice an attack was happening.
- Server-side request forgery. Tricking a server into making a request to a destination the attacker chose, often reaching internal systems that were never meant to be externally reachable.
It is a starting point, not a checklist
A test that only checks for these ten categories and calls itself thorough is missing the point. The list represents the most common, highest-impact risk categories, not an exhaustive inventory. A real engagement should use it as a shared vocabulary for reporting, not as the entire scope of what gets tested.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation