Vulnerability Classes

You are looking at your own invoice at /invoices/1041. Out of curiosity you change the number to 1042 and press enter. If somebody else's invoice appears, you have just found an insecure direct object reference — and you found it without tooling, without a payload, and in about four seconds. A great many real vulnerabilities are exactly this ordinary. They are not clever attacks on strong defences; they are functions that trusted a value they had no business trusting.

This track works through those functions as katas. Each one hands you the broken version, an exploit that demonstrates the break, and the job of repairing it so a test keeps it repaired. The first family is untrusted input treated as instruction. SQL injection happens because a string was concatenated into a query, so the database cannot tell your structure from the attacker's; parameterisation fixes it by keeping data out of the instruction stream entirely, which is why filtering quotes harder is the wrong shape of answer. Path traversal is the same failure against a filesystem, where ../ escapes the directory you meant to serve, and the fix is likewise structural — resolve the path and confirm it is genuinely inside the permitted root.

The second family is broken access control, which is the invoice above. IDOR is the caller choosing which object they operate on, and the fix is to scope the lookup to the authenticated identity rather than check a supplied id. Mass assignment is the caller choosing which fields they set, so a form that should update a display name also flips is_admin because the handler bound the whole request body to the model; the fix is an explicit allowlist of assignable fields. The OWASP Top 10 sits alongside as a map for orienting yourself in unfamiliar code — useful for knowing what to look for, and no substitute for having fixed one of each yourself.