security-auditlisted

# Security audit Two jobs: keep `criteria.md` current with the threats that actually apply to *this* app, then audit the code and configuration against it. The app already has a deliberate, documented security posture, so the realistic finding is a **regression or a subtle drift** — an auth cookie that lost `httpOnly`, a new write route with no zod schema, a bare `pool.query` on a round table, an `OR`ed RLS policy, a CSP directive quietly widened. Those are what the criteria target. **Read `.claude/skills/audit/audit-loop.md` first** — it owns the loop (research gating, the critique test, how criteria change, the report format, and the rule that findings only become issues with the user's approval). This file owns the domain: where the security surface is and how to probe it. Pass `--research` to force a research pass; otherwise the cadence in `criteria.md` decides (45 days). ## This is a defensive audit — the misuse boundary The purpose is to **find weaknesses in order to close them**, on the maintainer's own repo. Everything below is oriented toward a fix, and the skill must not become an attacker's playbook. Concretely: - **Never produce a weaponized artifact.** No working exploit, no copy-paste attack script, no step-by-step procedure for compromising the running service. Describe a finding as **weakness → impact → fix** at the minimum specificity a maintainer needs to remediate — never the maximum an attacker would need to execute. A proof-of-concept, when