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 the URL scheme and hostname, 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.

Triage audit findings by severity and reachability: fix reachable critical and high issues immediately, schedule moderate production issues for the next release, and track low-severity items. Never run npm audit fix --force blindly; preview changes, read changelogs, and test each upgrade.

No, express-rate-limit keeps counters in process memory by default, so each instance counts separately 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 for serverless runtimes.

Treat all LLM output as untrusted input: never pass it into eval, SQL, shell commands, or innerHTML. Parse it defensively with JSON.parse and a schema validator, then encode it before rendering, and keep secrets and other users' data out of the prompt context.

Rotate the secret immediately by revoking and reissuing the key, because deleting the line or rewriting history is not enough once it reaches a remote. After rotation, purge it from history and add the file pattern to .gitignore.