security-reviewlisted

# Security 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. The checklists below cover both; intent differs. --- ## Codebase review checklist ### Secrets & credentials - Grep for: `password`, `secret`, `api_key`, `token`, `BEGIN PRIVATE KEY`, AWS access key prefixes (`AKIA`, `ASIA`). - `.env`, `.env.*`, `config/*.yaml` - should never be committed. Check `.gitignore`. - `git log --all -p` for historical commits that leaked secrets. - Hardcoded JWT secrets, fallback admin passwords, default credentials → blocker. - Logger redact arrays must cover every API key / token / password the app handles. ### Input validation - Every external input (HTTP body/query/header/path, file upload, queue message, env var, deserialized blob) is validated at