security-reviewlisted

# Security review Audit the paths an attacker would walk, not a checklist. Every finding needs a concrete attack scenario; if you cannot describe the attack, it is a hardening suggestion, not a vulnerability. ## Method 1. **Map the trust boundaries first.** Where does data enter from outside (requests, files, env, third-party APIs, user uploads)? Where does the code do something privileged (queries, shell, filesystem, network, crypto, money)? Vulnerabilities live on paths from the first list to the second. 2. **Walk each path hunting the classics, in payoff order:** - Injection: user input reaching SQL, shell, path, template, or eval without parameterization or strict validation. String concatenation into any interpreter is guilty until proven safe. - Broken auth and authz: endpoints missing permission checks, ids taken from the client without ownership verification (IDOR), tokens that never expire, secrets compared with string equality. - Secrets in the wrong place: keys in code, tokens in logs, credentials in error messages or URLs. - Unsafe deserialization and parsing of untrusted data. - SSRF: user-influenced URLs fetched by the server without a host allowlist; redirects and DNS tricks bypass naive checks. - Path traversal: filenames from users joined into paths without canonicalization checks. - Missing limits: unbounded sizes, counts, depths, and rates, each a denial of service on a timer. 3. **