security-reviewlisted

## When to use - Reviewing a change that touches user input, auth, or data storage - A feature accepts untrusted data, manages sessions, or integrates with external services - Adding file uploads, webhooks, callbacks, or payment/PII handling - Before merge on any security-sensitive change - Triggers on "security review", "check for vulnerabilities", "安全审查", "安全审计", "漏洞检查" **Not for:** general code quality review (use `code-review`); performance profiling (use `performance`). ## Steps ### 1. Threat model first Controls bolted on without a threat model are guesses. Before reviewing hardening, spend five minutes thinking like an attacker: 1. **Map trust boundaries** — HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, **LLM output**. Every boundary is attack surface. 2. **Name the assets** — credentials, PII, payment data, admin actions, money movement. 3. **Run STRIDE** per boundary — Spoofing (auth, signature verification), Tampering (integrity, parameterized queries, HTTPS), Repudiation (audit logging), Information disclosure (encryption, field allowlists, generic errors), Denial of service (rate limiting, size caps, timeouts), Elevation of privilege (authorization checks, least privilege). 4. **Write abuse cases next to use cases** — "how would I misuse this?" is your first test. If you can't name the trust boundaries for a feature, it's not ready to secure (OWASP A04: Insecure Design — most breaches begin in design, not code). ###