security-reviewlisted

# Security review Find the vulnerabilities an attacker would, before they do, and report them precisely enough to fix. Review with the attacker's question: *what input or identity do I control, and where does it go?* ## Process 1. **Scope:** the diff or the components under review, the assets (money, PII, credentials, availability), and the trust boundaries (client ↔ server, service ↔ service, app ↔ device, tenant ↔ tenant). 2. **Threat-model the data flows** (STRIDE as a prompt): spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. For each boundary, ask what is validated, authenticated, authorized and logged. 3. **Walk the checklist** below against the actual code paths. Trace untrusted input to every sink. 4. **Run the project's tools, or propose them:** - secrets scanning (gitleaks, trufflehog); - dependency audit (`npm audit`, `osv-scanner`, `pip-audit`, Dependabot or Renovate alerts); - SAST (Semgrep, CodeQL); - the platform linters (Android Lint security checks, for example). 5. **Report** each finding with: - **severity** by real impact and likelihood (Critical / High / Medium / Low); - `file:line`; - the attack scenario (who, how, what they gain); - the fix. Separate **Confirmed** from **Needs verification**. Don't pad the report with generic advice. ## Checklist - **Injection:** parameterized SQL/ORM (no string concatenation); no shell with user input (pass argument arrays); output encod