Harden web applications with security-first development

Gives security-first development practices for web applications: treat every external input as hostile, every secret as sacred, and every authorization check as mandatory, since security is a constraint on every line of code touching user data, authentication, or external systems, not a separate phase. It works through a threat-model-first process, a three-tier rule system for what to always do, ask approval for, and never do, concrete prevention patterns mapped to the OWASP Top 10 including server-side request forgery with a TOCTOU caveat, input-validation and file-upload patterns, dependency-audit triage and supply-chain hygiene, rate limiting, secrets management, and a full section specifically for securing AI and LLM features mapped to the OWASP Top 10 for LLM Applications.

Use it when building anything that accepts user input, implementing authentication or authorization, storing or transmitting sensitive data, integrating with external APIs or services, adding file uploads, webhooks, or callbacks, or handling payment or PII data. Before hardening anything, spend five minutes threat-modeling like an attacker rather than bolting controls on as guesses: map every trust boundary where untrusted data crosses in (HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output all count), name the assets actually worth stealing or breaking (credentials, PII, payment data, admin actions, money movement), run the STRIDE lens across each boundary (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, each with its own typical mitigation), and write an abuse case next to every use case by asking how the feature could be misused, then make that the first test. Not being able to name a feature's trust boundaries means it isn't ready to be secured yet - this maps to OWASP's Insecure Design category, since most breaches start in design rather than code.

A three-tier rule system governs day-to-day work. Always do, no exceptions: validate all external input at the system boundary, parameterize every database query rather than concatenating user input into SQL, encode output through framework auto-escaping to prevent XSS, use HTTPS everywhere, hash passwords with bcrypt, scrypt, or argon2 rather than storing plaintext, set security headers, use httpOnly and secure and sameSite session cookies, and run a dependency audit before every release. Ask first, requiring human approval: new authentication flows or auth-logic changes, storing new categories of sensitive data, new external service integrations, CORS changes, file upload handlers, rate-limiting changes, and granting elevated permissions or roles. Never do: commit secrets to version control, log sensitive data, trust client-side validation as a security boundary, disable security headers for convenience, use eval or innerHTML with user-provided data, store session tokens in client-accessible storage like localStorage, or expose stack traces or internal error details to users.

Concrete prevention patterns exist for each major OWASP category: injection is prevented by parameterized queries or an ORM instead of string-concatenated SQL; broken authentication is prevented by password hashing at a real cost factor plus httpOnly and secure and sameSite session cookies read from environment configuration; XSS is prevented by framework auto-escaping or, when raw HTML must render, sanitizing it first rather than assigning straight to innerHTML; broken access control is prevented by checking resource ownership on every request, not just authentication; security misconfiguration is prevented by a security-header middleware plus a real Content-Security-Policy and a CORS policy restricted to known origins; sensitive-data exposure is prevented by stripping password hashes and reset tokens from any API response and reading secrets from environment variables that fail loudly if missing; and server-side request forgery, which is any case where the server fetches a URL the user influenced such as a webhook, an import-from-URL feature, an image proxy, or a link preview, is prevented by allowlisting scheme and host, resolving every DNS record and rejecting if any resolved address is a private or reserved range rather than a public unicast address, and forbidding redirects:

async function assertSafeUrl(raw: string): Promise<URL> {
  const url = new URL(raw);
  if (url.protocol !== 'https:') throw new Error('https only');
  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('host not allowed');
  const addrs = await lookup(url.hostname, { all: true });
  if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {
    throw new Error('private/reserved IP');
  }
  return url;
}

that unicast check alone covers loopback, link-local cloud-metadata addresses, private, and unique-local ranges across both IPv4 and IPv6, with an explicit caveat that this still has a TOCTOU gap since a short-TTL DNS record can rebind between validation and connection, so a high-risk surface should resolve once and connect to the pinned address or sit behind a dedicated filtering proxy. Input validation is enforced with a schema library validating at the route handler before any business logic runs, and file uploads are restricted by allowed MIME type and a maximum size, with a note that the file extension alone should never be trusted for anything security-critical. Triaging a dependency-audit report follows a decision tree by severity and reachability: critical or high findings get fixed immediately if the vulnerable code path is actually reachable, or fixed soon if it's a dev-only or unused path; moderate findings get fixed in the next release cycle if reachable in production or tracked in the backlog otherwise; and low findings just get tracked through regular dependency updates, with any deferred fix documented alongside its reasoning and a review date. Supply-chain hygiene goes beyond what an audit catches: commit the lockfile and install with a reproducible, frozen install command in CI rather than a mutable one, review every new dependency's maintenance and popularity before adding it since every dependency is attack surface, treat postinstall scripts in unfamiliar packages with suspicion since they run arbitrary code at install time, and watch for typosquatted package names that look almost identical to a popular one. Rate limiting applies a general window-and-max policy across the whole API and a stricter, tighter policy specifically on authentication endpoints. Secrets management keeps a committed example env file with placeholder values separate from real, gitignored env files, checks a staged diff for password, secret, and token-shaped strings before every commit, and treats any secret that ever reaches a remote as compromised the instant it's committed, rotating and reissuing the credential first and only then purging it from history, since deleting the line or rewriting history alone is never enough. Securing AI and LLM features maps to its own OWASP Top 10 for LLM Applications: treat all model output as untrusted input rather than ever passing it straight into eval, SQL, a shell, innerHTML, or a file path; assume prompts can be hijacked by untrusted text anywhere in the context window, so permissions get enforced in code rather than in the system prompt; keep secrets and other users' data out of any prompt, since anything in context can be echoed back; constrain tool and agent permissions to the minimum needed and require confirmation for destructive or irreversible actions; bound token, request-rate, and recursion-depth consumption so a crafted input can't run up cost or hang the system; and for retrieval-augmented generation specifically, treat the vector store itself as a trust boundary, partitioning embeddings per tenant and validating documents before indexing so poisoned content can't steer answers. A full security-review checklist, a table of common security rationalizations paired with why each one is wrong, and a list of concrete red flags to scan for round out the reference, alongside a final verification checklist to run after implementing any security-relevant code.

Developers building anything that touches user input, authentication, sensitive data, external integrations, or LLM features who want concrete, code-level prevention patterns and a threat-modeling process rather than vague security advice, plus a checklist to verify the work afterward.