Owasp Web

Web failure classes

These classes recur because frameworks make the unsafe version shorter to write. Finding them is reading for a pattern — untrusted input reaching somewhere that treats it as instruction — not reciting a taxonomy. A class you name without a file and a path is not a finding.

When this fires

Code that receives requests, builds queries, renders output, fetches URLs, parses serialized data, handles sessions or accepts files is being written or reviewed. Use it inside a review pass, or on its own when asked to sweep an app for the usual suspects.

Procedure

1. Enumerate the untrusted entry points first. Route tables and handlers, GraphQL resolvers and their nested fields, webhook receivers, queue consumers, file uploads, CLI and admin scripts, anything parsing a header or cookie. Every class below is checked from these, not by browsing files alphabetically.
2. Broken access control, before anything else. It is the most common and the least visible to tooling. Look for a handler taking an id from the path, body or query and fetching without scoping to the caller; middleware applied by opt-in so a new route is unprotected by default; bulk and batch endpoints checking only the first item; a role or tenant id read from the request. See the authorization skill for the model itself.
3. Injection — find where data reaches an interpreter as syntax. SQL built by concatenation or template literals, an ORM's raw escape hatch, a shell invoked with a command string rather than an argument vector, a query object built straight from a JSON body, an LDAP or XPath filter, a template rendered from a user-supplied string, eval and its relatives. The fix is parameterization or passing arguments as data — hand-rolled escaping is a defect with a delay.
4. XSS is an output-context question. Ask where the string lands: HTML body, attribute, URL attribute, inside a script, inside CSS. Look for raw-HTML sinks (innerHTML and each framework's dangerous-HTML prop), auto-escaping turned off, user text interpolated into an inline script or a href, Markdown rendered to HTML without sanitisation, and SVG or HTML uploads served from the app's own origin. Escaping correct for one context is wrong in another.
5. SSRF — anywhere the server fetches a URL a user influenced. Webhook targets, avatar and image fetchers, link previews, PDF and screenshot renderers, import-from-URL, identity discovery documents. Check for an allowlist of destinations, whether redirects are followed blindly, and whether the check happens before or after DNS resolution. Blocking metadata addresses by string match is not a control: alternate encodings, IPv6, redirects and rebinding all walk past it.
6. Deserialization and object binding. Untrusted bytes reaching a language's native deserializer, a YAML loader that constructs arbitrary types, or JSON that names its own class, is remote code execution waiting for a gadget. Alongside it: mass assignment binding a whole request body onto a model (isAdmin arrives free), and merge helpers in JavaScript that let a body reach the prototype chain.
7. Sessions and tokens. Where is a session created, rotated on privilege change, and invalidated on logout and password change? Cookie flags set? Password-reset tokens random, single-use and short-lived? For signed tokens, check that verification pins the algorithm and the key and checks expiry and audience — accepting whatever algorithm the token names is the classic hole.
8. Secrets and inadvertent disclosure. Keys committed to the repository or baked into a client bundle by a public-prefixed environment variable, tokens in URLs and logs, stack traces and debug routes reachable in production, error messages distinguishing "no such user" from "wrong password" where that matters.
9. File handling. Path traversal in download and upload names, archive extraction writing outside its target directory, trusting a client-declared content type, and serving user files from the application's origin where they inherit its cookies and permissions.
10. Dependencies: audit output is leads, not findings. Run the ecosystem's audit, then check whether the vulnerable code path is actually reachable from step 1's entry points. Reporting an advisory list as a security review is how real findings get ignored.
11. Confirm reachability before reporting. Source, sink, and a path between them that survives the checks in between. Without that path, report it as hardening and label it so.

Sending payloads at a running system is a different act from reading code. It stops and asks first, names the target, and does not happen against production or anything the user has not said they own. Reading is always in scope; probing is not implied by it.

Checklist

• Entry points enumerated before any class was checked
• Access control checked per handler, including bulk endpoints and new-route defaults
• Every interpreter boundary found and checked for parameterization
• Output sinks checked per context, including uploads served from the app origin
• Every server-side fetch of a user-influenced URL identified
• Deserializers, model binding and merge helpers traced back to untrusted input
• Session lifecycle and token verification read, not assumed
• Repository, logs, bundles and error paths checked for secrets and disclosure
• File name, archive and content-type handling checked
• Dependency advisories triaged for reachability
• Each reported item has a source, a sink and a path; hardening labelled as hardening
• Nothing was probed against a live system without asking

Failure handling

• The pattern appears but the input turns out to be trusted — drop it or downgrade it to hardening. A false positive costs more than a missed low-severity issue: it teaches the reader to skim.
• A framework may already neutralise it — check the framework's actual behaviour for that version rather than assuming either way, and say which behaviour you relied on.
• The sink is reached through code you cannot follow (dynamic dispatch, generated code, a vendored blob) — report it as an unresolved path with what you traced, not as safe.
• A class cannot be checked at all — no access to the templates, the infra config, the dependency lockfile — name it as unchecked in the report. Silence reads as a pass.
• Something looks exploitable — that is a hypothesis until it is run by someone authorized to run it. Write it as "reachable by inspection", not "exploitable".

Evidence to report

Per finding: file and line, the untrusted input, the sink, the path between them, the concrete consequence to a named asset, and the smallest fix. Per review: which entry points were enumerated, which classes were checked, which were not checked and why, audit output with its reachability triage, and everything reasoned about but not run, said so plainly.