security-and-hardening

Prevent SQL injection by using parameterized queries or an ORM instead of concatenating user input into SQL strings. Pass user values as bound parameters, for example db.query('SELECT * FROM users WHERE id = $1', [userId]).

Set session cookies with httpOnly, secure, and sameSite flags so JavaScript cannot read them and cross-site requests cannot attach them. Hash passwords with bcrypt at 12+ salt rounds and keep session secrets in environment variables, never in code.

Triage audit findings by severity and reachability: fix reachable critical or high issues immediately, schedule moderate production issues for the next release, and track low ones. Never run forced audit fixes automatically; preview changes and read changelogs first.

SSRF occurs when a server fetches a user-influenced URL, letting attackers reach internal services like cloud metadata endpoints. Prevent it by allowlisting hosts, requiring HTTPS, rejecting any resolved private or reserved IP, and disabling redirects.

In-memory rate limiters fail across multiple instances because each process keeps its own counter, and serverless invocations start from zero. Use a shared store such as Redis via rate-limit-redis or an HTTP-based limiter like @upstash/ratelimit.

Always treat LLM output as untrusted, since it can contain SQL, script tags, or shell commands injected via prompts. Parse it defensively with a schema, validate before use, and never pass it to eval, innerHTML, or raw queries.