reviewing-for-securitylisted

# Reviewing for security Most real vulnerabilities are ordinary code with one missing check. You are looking for the path from something a stranger controls to something that matters. ## Follow the untrusted input Start at the edges — request bodies, query strings, headers, file uploads, webhook payloads, file names, environment on a shared host, and anything a user typed — and follow each one to where it lands: - **into a query** → is it parameterised, or is it string-concatenated? Concatenation is the bug, even when the value "obviously" cannot contain a quote. - **into a shell** → is it an argument array, or a formatted command string? Passing a list of arguments is the fix; escaping by hand is not. - **into a path** → can it contain `..` or an absolute path and escape the directory? Resolve, then check the result is still inside where it should be. - **into HTML or a template** → is it escaped at the point of output? - **into a URL the server fetches** → can it be pointed at localhost or the cloud metadata service? - **into a deserializer, a template engine, or `eval`** → this is almost always wrong; ask why. ## Then check authorisation, not just authentication Knowing who someone is and knowing what they may do are different checks, and the second is the one that gets forgotten. - Every handler that acts on an object: does it check this user may touch *this* object, not merely that they are logged in? - Is the check on the server, or only in the interface?