security-reviewlisted

# Security review For a general break-it pass use `adversarial-review`. ## Authorization gate (read first) Before testing any *running* system, confirm scope and authorization in writing: - Is this our system, a CTF, a personal lab, or a paid pentest engagement? - What targets / IPs / domains are in scope? What is explicitly out of scope? - What testing methods are allowed? (DoS, social eng, supply chain - usually out of scope by default.) - What is the rules-of-engagement for findings disclosure? If any of this is unclear, **stop and ask the user** before sending packets. Codebase review needs no such gate - read freely. ## Two modes - **Mode A - Codebase review (static).** You're reading source. Look for vulnerable patterns, not exploits. - **Mode B - Live target testing (dynamic).** You're poking a running system. Authorized only - see gate above. Per-category commands, grep patterns, and OWASP specifics live in `references/checklist.md` - work from it during the pass. ## Decision rules - Any string-built SQL, shell command, or template fed user input is a blocker - parameterized queries and arg arrays only. - Validate every external input at the boundary with a schema; type coercion is not validation. - Authorization is per-request, not per-session: every endpoint checks "can THIS user access THIS resource?" - IDOR is one missing check away. - Secrets live in env or a secret store; hardcoded fallback credentials and committed `.env` files are blockers. - Use libra