security-checklistlisted

## Purpose A security review without a structure tends to catch whatever the reviewer happens to think of that day and miss whatever they don't. This checklist gives a repeatable set of categories to walk through explicitly for any change that touches input handling, auth, data access, or external systems, so coverage doesn't depend on what's top of mind. It's the working tool behind the `security-auditor` agent, but it's usable by anyone reviewing a diff. ## When to use it For any change touching: user input (forms, query params, file uploads, API payloads), authentication or authorization logic, database queries, file paths or filesystem access, external API/network calls, cryptography or session/token handling, or dependency additions/updates. Skip it for changes with none of the above (e.g., a pure UI copy change) — mark the whole review N/A rather than force-fitting categories that don't apply. ## The checklist Walk each category and mark it PASS (verified, no issue), FAIL (issue found — blocking), or N/A (doesn't apply to this diff), with a one-line note for anything not PASS/N/A: 1. **Injection** — Are all queries parameterized (no string-concatenated SQL)? Are shell commands built without interpolating untrusted input? Are file paths validated against traversal (`../`) before use? Is user input reflected into templates/HTML escaped by default? 2. **Authentication** — Does this path require authentication where it should? Are session/token checks happening on eve