security-audit-checklistlisted

## Purpose Give a security review a fixed, repeatable shape so two different reviewers checking the same change produce comparable results, and so nothing gets skipped because it wasn't top of mind that day. ## When to use it Any time you're reviewing a diff, a pull request, or a codebase specifically for security issues — whether that's the `security-compliance-auditor` agent doing a full pass or a quick self-check before a change ships. Run through every category below; mark items N/A with a one-line reason rather than silently skipping them. ## Checklist For each item: record **PASS**, **FAIL**, or **N/A**. Every FAIL needs a concrete failure scenario (the specific input/state and the specific bad outcome) and, where it fits, a citation (CWE number, OWASP Top 10/ASVS category, or NIST SSDF practice). ### Injection - User-controlled input never reaches a SQL query, shell command, template engine, or log sink by string concatenation or interpolation — parameterized queries, prepared statements, or an equivalent safe API are used instead. (Maps to CWE-89, CWE-78, OWASP A03:2021 – Injection.) - Any use of `eval`, dynamic code execution, or deserialization of untrusted data is either absent or explicitly justified and sandboxed. ### Authorization and authentication - Every endpoint or handler that touches non-public data checks both that the caller is authenticated *and* that they're authorized for the specific resource being accessed (object-level authorization, not jus