security-and-hardening

Prevent SQL injection by using parameterized queries instead of string concatenation, such as db.query('SELECT * FROM users WHERE id = $1', [userId]), or an ORM like Prisma with typed inputs. Validate all external input at the route boundary with a schema validator like zod.

Protect against SSRF by allowlisting schemes and hosts, resolving all DNS records and rejecting any private or reserved IP range, and disabling redirects. For high-risk surfaces, pin the resolved IP or use a filtering agent, since DNS rebinding creates a TOCTOU gap between validation and connection.

Set session cookies with httpOnly, secure, and sameSite flags so they are inaccessible to JavaScript, sent only over HTTPS, and protected against CSRF. Hash passwords with bcrypt, scrypt, or argon2, and apply stricter rate limits to authentication endpoints.

Triage audit findings by severity and reachability: fix reachable critical or high findings immediately, schedule moderate ones for the next release, and track low ones. Never run forced fixes like npm audit fix --force automatically; review changelogs and test each upgrade.

LLM output is untrusted because prompts can be hijacked by injected instructions, and model text can contain SQL, scripts, or shell commands. Never pass it to eval, innerHTML, or a query directly; parse it defensively, validate against a schema, and encode it before use.

Use a shared store such as Redis once more than one process serves traffic, because in-memory limiters give each instance its own counter and serverless invocations reset to zero. Tools like rate-limit-redis or @upstash/ratelimit enforce limits consistently across instances.