About this interactive
The OWASP Top 10 is a ranking of the risks that actually get web applications broken into, and the reason it is hard to learn is that the categories overlap in vocabulary while staying sharply distinct in mechanism. Almost every item here could be described as "unvalidated user input," which is true and useless. The question that sorts them is narrower: what does the attacker's input reach, and what runs it? Start with the pair students confuse most, Injection and Cross-Site Scripting, because they are genuinely siblings — both send hostile text into a field the application will hand to an interpreter. The discriminator is which interpreter, and therefore who gets hurt. In Injection the interpreter is on the server: a SQL engine, an operating system shell, an LDAP directory. The login form that lets ' OR '1'='1 through is not confusing a browser about anything; it is building a query string that the database parses as logic instead of as data, so the WHERE clause becomes universally true and authentication collapses. The admin panel that passes a user-supplied filename into an OS command is the same failure against a different interpreter — the shell sees a metacharacter, and what was meant to be a filename becomes a second command. The payload executes on the server, with the server's privileges, and the victim is the application itself. In XSS the interpreter is a browser, and not the attacker's browser — someone else's. The comment field that stores input unescaped is the stored variant: the payload is written to the database once and served to every visitor who loads the page, so a single submission compromises every reader. The search page that reflects a query parameter into the HTML without encoding is the reflected variant: the payload lives in a crafted link, and the victim is whoever is tricked into clicking it. Both send the attacker's script into a victim's session where it can steal cookies or act as that user. So: server-side interpreter is Injection, victim's browser is XSS. The same discipline resolves SSRF against CSRF, which sound almost identical and point in opposite directions. In SSRF the confused deputy is the server. The attacker supplies a URL, the server fetches it, and because the request originates inside the network it reaches things the attacker cannot reach directly. The AWS metadata address 169.254.169.254 is the classic proof: it is a link-local address that only an instance can reach, it requires no authentication, and it will hand back IAM credentials to anything that asks — so a server that fetches an attacker-chosen URL will happily fetch its own keys and return them. The file-upload feature that pulls a remote URL is the same weakness used for reconnaissance instead, aiming the server at internal addresses and reading the timing and error differences to map a network from the outside. In CSRF the confused deputy is the victim's browser, and the direction reverses: the attacker never touches the server directly but tricks an already-authenticated browser into submitting a request, exploiting the fact that the browser attaches session cookies automatically. SSRF abuses the server's ability to make outbound requests; CSRF abuses the browser's willingness to make authenticated ones. Neither CSRF item appears in this activity — that is deliberate, because the contrast is what makes SSRF legible, and holding the distinction is the point. Broken Access Control and Authentication and Session Failures divide along the older line between authorization and authentication. Broken Access Control assumes the login worked: you are exactly who you say you are, and the application still lets you reach something that is not yours. Typing /admin/users and arriving there means no check was made at the point of use, only, at best, a hidden menu link — and hiding a control is not enforcing one. Changing an order ID in the URL and seeing someone else's history is the same failure with a name of its own, an insecure direct object reference: the application trusted a value the user could edit to decide which record to return. Authentication and Session Failures are one level earlier, in the machinery that establishes and maintains identity. Tokens that never expire mean a stolen token is a permanent key rather than a temporary one, which is why session lifetime is a control and not a convenience. A login with no rate limit and no lockout makes ten thousand guesses a second an available strategy, which turns every weak password in the user base into a certainty rather than a risk. The trap in this section is the default admin credentials, which feel like an authentication failure and are not: the authentication mechanism is working exactly as designed and correctly verifying a password that everyone on the internet already knows. Nothing is broken in the code — a setting was left at its shipped value, which makes it Security Misconfiguration. That category is best understood by asking who owns the fix. Misconfiguration is a setting you control and left wrong: unchanged defaults, and verbose error pages that hand unauthenticated visitors stack traces with file paths and database versions, which is free reconnaissance that turns a blind attack into a targeted one. Vulnerable and Outdated Components is code someone else wrote that you have not updated: an image library with a published critical RCE eighteen months old, or a CMS three years behind and falling to an exploit anyone can download. The distinction is real because the remediation is different — one is a configuration change you can make this afternoon, the other is a patch, an upgrade, and a dependency inventory, which is why software composition analysis exists as a separate practice. Note also what makes these two items dangerous: the vulnerability being publicly known and the exploit being publicly available means the attacker needs no skill, only a scanner. Cryptographic Failures covers both states of data. At rest, passwords in unsalted MD5 are a double failure: MD5 is cryptographically broken and fast to compute, and the missing salt means identical passwords produce identical hashes, so a precomputed rainbow table cracks the whole database at once rather than one account at a time. In transit, session tokens sent over HTTP rather than HTTPS are readable by anyone on the path, and a captured token is a session — no password needed. The unifying idea is that the data was sensitive, protection was available, and the wrong protection or none was applied. Work every scenario the same way. Ask what the attacker supplies, what component consumes it, and what that component does with it. The category follows from the mechanism, and the words in the description are frequently a decoy.