Security headers, CORS, and TLS posture

Security response headers: each one blocks a named attack

A security response header is a directive you send on every response that reconfigures the browser’s own defenses. It costs nothing at runtime and is the cheapest layer you own, but each header is paired with a specific attack — set the wrong one and you get a false sense of safety. When you review a new deployment, these six headers should be the first thing you check on the response.

• Content-Security-Policy is the heavy hitter. It tells the browser which sources may load and execute resources, so an injected <script> from an XSS payload simply doesn’t run. script-src 'self' means “only scripts served from my own origin execute”; inline <script> blocks and onclick= handlers are refused. The proper way to allow a known inline block is a per-response nonce (script-src 'nonce-r4nd0m', matched by <script nonce="r4nd0m">) or a content hash. The trap: adding 'unsafe-inline' to make a legacy widget work re-enables every inline script — which defeats the whole point, because the XSS payload is inline script. A strict CSP is the single biggest XSS reducer you can deploy, but it is also the most likely to break a page, so roll it out with Content-Security-Policy-Report-Only first and watch the violation reports.
• Strict-Transport-Security (HSTS) tells the browser “for the next N seconds, never speak HTTP to this host — upgrade to HTTPS before sending anything.” That closes the SSL-strip window where a network attacker downgrades the first plaintext request and MITMs the session. max-age=31536000 is one year; includeSubDomains extends it to every subdomain; preload (after submitting to the browser preload list) means the very first request is already protected, with no trust-on-first-use gap.
• X-Content-Type-Options: nosniff stops the browser from second-guessing your Content-Type. Without it, a browser may “sniff” a user-uploaded file you served as text/plain and decide it’s actually HTML or JavaScript, executing it. One header, MIME-confusion class gone.
• Clickjacking — your page loaded invisibly inside an attacker’s <iframe> over a decoy UI — is blocked by Content-Security-Policy: frame-ancestors 'none' (the modern control) or the older X-Frame-Options: DENY. Send frame-ancestors; keep X-Frame-Options only for ancient clients.
• Referrer-Policy: strict-origin-when-cross-origin trims the Referer header so you don’t leak full URLs (with tokens in the path or query) to third-party origins.

import http from "node:http";

http.createServer((req, res) => {
  // raw: explicit, dependency-free, easy to get subtly wrong at scale
  res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'; frame-ancestors 'none'");
  res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload");
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.end("ok");
}).listen(3000);

import express from "express";
import helmet from "helmet";

const app = express();
// helmet sets a sane bundle (CSP, HSTS, nosniff, frame-ancestors, referrer) in one line.
// You still own the CSP — its default is strict and will block inline scripts until you add a nonce.
app.use(helmet());

The tradeoff is concentrated in CSP. helmet() hands you most headers for free, but the strict CSP it ships will break inline scripts and any third-party widget that injects script — so the work is not “turn it on,” it’s “enumerate your real sources, add nonces or hashes, run report-only, then enforce.” Skipping that rollout is why teams reach for 'unsafe-inline' and quietly throw the protection away.

CORS: the server opting in to cross-origin reads

The most misunderstood thing about CORS is that it is not a feature you enable to make requests work — it is the browser’s relaxation of a default prohibition. The Same-Origin Policy is the baseline: a page on https://app.com may send a request to https://api.com, but the browser will not let the page read the response unless the responding server explicitly says so. CORS is that “explicitly says so.”

For a simple request (a plain GET/POST with only safe headers), the browser sends it and then checks the response: if Access-Control-Allow-Origin matches the page’s origin, the JavaScript may read the body; if not, the request still hit your server but the browser hides the response from the script.

For a non-simple request — a PUT/DELETE, a JSON Content-Type, or a custom header like Authorization — the browser first sends a preflight: an OPTIONS request carrying Access-Control-Request-Method and Access-Control-Request-Headers. Your server must answer with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers that cover what was asked. Only if the preflight passes does the browser send the real request — and only then expose its response.

The credentials trap: how a CORS “fix” becomes account takeover

Here is the war story in mechanism form. The spec forbids combining Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — the browser flatly rejects that pairing, because a wildcard plus cookies would mean any site could make authenticated reads. So a wildcard can never carry credentials, which is safe by design.

The danger is the “fix” teams reach for when the SPA needs cookies and the wildcard stops working. They make the server reflect the request Origin back — cors({ origin: true }), or hand-rolled res.setHeader('Access-Control-Allow-Origin', req.headers.origin) — together with Access-Control-Allow-Credentials: true. Now the server says “yes” to whatever origin asks, with credentials. That is functionally identical to the forbidden wildcard-plus-credentials, except the spec can’t stop it because each individual response looks origin-specific.

// ❌ THE TRAP: reflect any origin, with credentials. Every site is now allowed.
app.use((req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", req.headers.origin ?? "*"); // echoes evil.example too
  res.setHeader("Access-Control-Allow-Credentials", "true");
  next();
});

// ✅ THE FIX: validate Origin against an explicit allow-list before reflecting.
const ALLOWED = new Set(["https://app.yourapp.com", "https://admin.yourapp.com"]);
app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && ALLOWED.has(origin)) {
    res.setHeader("Access-Control-Allow-Origin", origin); // reflect ONLY allow-listed origins
    res.setHeader("Vary", "Origin");                      // cache correctly per-origin
    res.setHeader("Access-Control-Allow-Credentials", "true");
  }
  // no Origin header, or not allow-listed → emit nothing; browser blocks the read
  next();
});

The exploit flow is exactly the hook: attacker hosts evil.example, a logged-in victim visits, the page does fetch(api, { credentials: 'include' }), the browser attaches the session cookie, your reflect-everything server returns Allow-Origin: evil.example + Allow-Credentials: true, and the attacker’s script reads the authenticated response — profile, tokens, anything that endpoint returns. The fix is non-negotiable: never reflect an arbitrary origin with credentials. Validate against an allow-list, emit Vary: Origin so a shared cache doesn’t serve one origin’s header to another, and reflect only when the origin is known. (SameSite cookies — covered with session auth — are a second, partial line of defense here, but the CORS allow-list is the one you control directly.)

TLS posture: terminate it correctly, or the headers don’t matter

Every header above assumes the connection is actually private. TLS posture is getting that termination right.

• Minimum version TLS 1.2, prefer 1.3. TLS 1.0/1.1 are broken and must be off. Beyond security, 1.3 is faster: its handshake is 1-RTT versus 1.2’s 2-RTT, and 1.3 supports 0-RTT resumption — measurable latency on every new connection. Disable legacy ciphers and insecure renegotiation.
• Serve the complete certificate chain. Your leaf cert must be sent with its intermediate(s). A missing intermediate is the classic “works in my browser, breaks in production” trap: browsers often cache intermediates or fetch them via the AIA extension and paper over the gap, but many API clients, mobile SDKs, and older stacks do not — they fail the handshake outright. So it passes your manual check and breaks for a third of your integrations.
• OCSP stapling lets your server attach a fresh, signed revocation proof to the handshake, so clients don’t make a separate (slow, privacy-leaking, sometimes-failing) call to the CA.
• Where to terminate. Terminating at a proxy or load balancer (nginx, ALB, Cloudflare) is the common, operationally simpler choice. Terminating in Node directly (https.createServer with minVersion: 'TLSv1.2') is fine for self-contained services. Either way, when a proxy terminates and forwards plaintext to Node, only trust X-Forwarded-Proto from that known proxy — set app.set('trust proxy', ...) to a specific hop, never blindly, or a client can spoof X-Forwarded-Proto: https and defeat your “redirect to HTTPS” logic.

import https from "node:https";
import { readFileSync } from "node:fs";

https.createServer(
  {
    key: readFileSync("privkey.pem"),
    // fullchain = leaf + intermediates. Serving only the leaf is the missing-chain bug.
    cert: readFileSync("fullchain.pem"),
    minVersion: "TLSv1.2", // floor; 1.3 negotiated when both sides support it
  },
  (req, res) => res.end("secure"),
).listen(443);