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 used correctly.

Prevent SSRF by allowlisting schemes and hosts, resolving all DNS records and rejecting any private or reserved IP range, and disabling redirects. Note the TOCTOU gap: for high-risk surfaces, pin the resolved IP or use a filtering agent like request-filtering-agent.

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

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

Treat all LLM output as untrusted input: never pass it to eval, SQL, shells, or innerHTML. Parse it defensively with JSON.parse and schema validation, 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. Assume the credential is compromised the moment it is pushed.