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]). ORMs like Prisma also parameterize inputs automatically when you pass values through their query APIs.

Configure session cookies with httpOnly to block JavaScript access, secure to require HTTPS, and sameSite set to lax or strict for CSRF protection. Hash passwords with bcrypt at 12 or more salt rounds and never store auth tokens in localStorage.

Allowlist the URL scheme and hostname, resolve all DNS records, and reject any address that is not public unicast, which blocks loopback and the 169.254.169.254 cloud metadata endpoint. Disable redirects and be aware of DNS-rebinding TOCTOU gaps on high-risk surfaces.

Fix critical and high findings immediately when the vulnerable code is reachable in runtime, build, or deployment paths; otherwise schedule them. Moderate issues go into the next release cycle, and low-severity items are handled during regular dependency updates with documented deferral reasons.

LLM output is untrusted input that can contain SQL statements, script tags, or shell commands, enabling injection or stored XSS. Parse it defensively with a schema like Zod, run only allowlisted actions, and render it as text content rather than HTML.

No, express-rate-limit keeps counters in process memory by default, so each instance maintains its own count and the effective limit multiplies by instance count. Use a shared store such as Redis via rate-limit-redis or an HTTP-based limiter like @upstash/ratelimit.