Harden web applications with security-first development

Security and Hardening organizes web-application security around trust boundaries, protected assets, and explicit abuse cases. Before choosing controls, it maps entry points such as requests, uploads, webhooks, third-party responses, queues, and model output, then applies STRIDE to consider spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation. The resulting threats determine what needs validation and which failures to test.

The guide combines application controls with dependency review, secret handling, and safeguards for model-backed features. Its code blocks are independent sketches with missing imports or adapters, not a complete tested server. A passing scanner or checklist is not security certification, and exact OWASP editions or category numbers need verification before citation.

Use it when building features that accept user input, authenticate users, authorize actions, store sensitive data, integrate external services, process uploads or callbacks, or handle payments and PII. Existing explicit authorization covers the requested implementation. New sensitive-data categories, destinations, permission grants, or production effects require the appropriate owner's authority.

Avoid relying on client validation as a boundary, storing plaintext passwords, committing credentials, logging sensitive values, exposing stack traces, or using untrusted content directly as executable code or HTML. Framework defaults and internal-only deployment do not remove the need to inspect actual controls. Scope and project context must determine the implementation and review.

Inputs include the feature's data flows, assets, identities, permission model, external destinations, and deployment context. Outputs can include a threat model, abuse-case checks, reviewed boundary controls, dependency-risk decisions, and a task-specific security review checklist.

Boundary validation uses schemas with explicit fields, types, length limits, and error handling. Tenant and owner identity come from the server rather than writable request fields. Parameterize database queries, for example:

const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

Authentication guidance covers reviewed password KDF settings, secure session cookies, an appropriate production session store, session identifier rotation, revocation, expiring reset tokens, and CSRF protection for cookie-authenticated writes. Authorization must check ownership and allowed actions, including atomic owner predicates in writes. Sensitive data needs appropriate encryption at rest and in transit. Output uses escaping or reviewed sanitization and explicit public-field allowlists, with generic errors that avoid private details.

Security configuration includes HTTPS, CSP, HSTS, frame and content-type headers, and CORS aligned with the endpoint's actual trust model. Credentialed origins need an explicit approved list; public noncredential resources can legitimately have wildcard origins. Authentication endpoints require rate limits, and response headers need inspection in the running application.

The TypeScript sketches use Express-oriented middleware, Zod, Prisma, bcrypt, DOMPurify, Helmet, and express-rate-limit as examples. Their presence does not establish a completed integration or justify executing unreviewed code.

For server-side URL fetching, the guide requires approved HTTPS destinations, controlled ports and credentials, address checks, and bounded responses, time, and concurrency. Its sample DNS check is explicitly partial: a later fetch can resolve again and create a TOCTOU rebinding gap. A reviewed transport must connect only to approved resolved addresses while retaining TLS hostname verification, with network egress restrictions and revalidation of permitted redirects.

Upload checks go beyond MIME and extension hints. They include streaming limits, content inspection, isolated image decoding or re-encoding, safe random storage names, owner authorization, quotas, and response headers. Malformed files and decompression bombs should fail rather than reach executable storage paths.

Supply-chain review uses committed lockfiles and reproducible CI installs, considers package maintenance and lifecycle scripts, and checks typosquatting risk. The npm audit command covers known advisories in its selected database, not malicious packages in general. Triage considers severity, runtime and build reachability, available fixes, and repository risk policy. Deferred findings need evidence, a reason, and a review date.

Secrets belong outside committed files and shared logs. Review staged paths and use a redacting scanner rather than printing candidate values. A remotely committed secret requires revocation and reissue; deleting a line or rewriting history alone is insufficient. Shared-history changes require coordination.

The guide serves web developers implementing security-sensitive application paths, including chat, summarization, and retrieval features. Model output remains untrusted data: parse, schema-validate, authorize, and encode it before use. Prompts do not enforce permissions, and allowlisted actions still need tenant checks and idempotency. Keep secrets and cross-user data out of context, constrain tool arguments and privileges, bound tokens and loops, and partition retrieval data by tenant. These controls complement the ordinary authentication, authorization, input, data, infrastructure, and supply-chain checks rather than replacing them.