security-and-hardening

Prevent SQL injection by using parameterized queries or an ORM instead of string concatenation. Pass user input as bound parameters, for example db.query('SELECT * FROM users WHERE id = $1', [userId]), so input is never interpreted as SQL syntax.

Protect against SSRF by allowlisting schemes and hosts, resolving all DNS records, and rejecting any private or reserved IP ranges including 169.254.169.254. Disable redirects and be aware of DNS-rebinding TOCTOU gaps, which require pinned IPs or a filtering agent for high-risk surfaces.

Secure session cookies require the httpOnly flag to block JavaScript access, the secure flag for HTTPS-only transmission, and sameSite set to lax or strict for CSRF protection. Never store auth tokens in localStorage, and hash passwords with bcrypt, scrypt, or argon2.

Triage audit results by severity and reachability: fix reachable critical and high findings immediately, schedule moderate production issues for the next release, and track low findings. Never run forced fixes like npm audit fix --force without reviewing changelogs and testing upgrades.

Yes, LLM output must be treated as untrusted input under OWASP LLM05. Never pass it directly into eval, SQL, shells, or innerHTML; instead parse it defensively, validate against a schema, and encode it before rendering or execution.

Approval is required before adding authentication flows, storing new PII categories, changing CORS configuration, adding file upload handlers, modifying rate limits, or granting elevated permissions. Routine controls like input validation and output encoding are always applied without asking.