Security response headers

What it is and why it exists

A security response header is a field that a server puts in an HTTP response so the browser enforces an additional security rule. These headers do not change an authorization decision already made by the server, and they do not sanitize untrusted input. They control what the browser may load, execute, send, or expose after receiving the response.

A web page handles documents, scripts, styles, images, forms, and embedded content at once. HTML and JavaScript alone cannot easily establish one consistent boundary that page scripts cannot casually rewrite. Response headers carry that boundary with a resource and can cover templates, static assets, and error pages.

This is defense in depth. The application still has to prevent XSS at its source; Content Security Policy (CSP) can limit script execution and data exfiltration after an injection occurs. TLS still provides connection confidentiality and integrity; HTTP Strict Transport Security (HSTS) tells a browser that knows the policy not to try plaintext HTTP again.

You encounter these headers in application frameworks, middleware, reverse proxies, API gateways, and CDN configuration. Final behavior depends on the complete response the browser receives, not on what any one layer intended to send. Policy design and deployment verification must therefore cover success, redirect, and error paths together.

Common headers solve different problems and cannot replace one another:

How it works

The server sends a response body after the status line and response headers. The browser parses policies that apply to that response, then decides how to handle the body and later subresource requests. Different headers act at different stages, so “the header exists” is only the start of an audit; its value, response type, and browser context matter too.

CSP’s decision order

A CSP consists of semicolon-separated directives. Fetch directives such as script-src, style-src, img-src, and connect-src constrain scripts, styles, images, and network connections respectively. Many resource types fall back to default-src when their dedicated fetch directive is absent; frame-ancestors, base-uri, and form-action do not use that fallback and must be set explicitly when needed.

The broader a source expression is, the more content the browser accepts. 'self' means the protected document’s own origin, while 'none' allows no source. Allowing all of https: or a broad host wildcard can still trust a source an attacker controls; derive a policy from the application’s real dependencies instead of starting with “allow the internet.”

A strict script-src blocks inline scripts by default. When inline script must remain, generate an unpredictable, single-use CSP nonce for the response and put the same value in both the policy and approved <script> elements. A nonce proves only that the browser may execute that element; it does not replace safe serialization of data inserted into the element.

Other headers keep their own state

HSTS is time-bounded state that a browser stores by host. A browser accepts the HSTS header only from a secure HTTPS response; on a later visit to a matching host, it upgrades an HTTP URL to HTTPS before making the network request. includeSubDomains extends the rule to subdomains, and preload expresses the site’s intent to enter the browser preload mechanism, but writing that token alone does not register the site.

Use X-Content-Type-Options: nosniff with an accurate Content-Type. It is not a replacement for MIME type detection; it tells the browser not to execute a response with the wrong type as a script or style in the relevant contexts. Uploaded content still needs safe filenames, a separate origin, download semantics, and server-side validation.

Referrer-Policy selects how much Referer data accompanies navigation or subresource requests. strict-origin-when-cross-origin keeps a full URL for same-origin requests, sends only the origin cross-origin, and sends no referrer on an HTTPS-to-HTTP downgrade. A sensitive page can use no-referrer, but the primary rule remains: do not put tokens, passwords, or personal data in a URL.

Permissions-Policy declares an allowlist per feature: for example, camera=() disables the camera and geolocation=(self) limits geolocation to the same origin. It controls whether a feature is available to a document; an actual call may still require user consent. Browsers may ignore feature names they do not recognize, so test final behavior in the browsers you support.

Policy ownership

A response may pass through an application, middleware, reverse proxy, and CDN. If several layers write the same header, the result may contain duplicate fields, overridden directives, or configuration that applies only to some status codes. The team should name one final policy owner and document other responsibilities—for example, the application supplies a per-response nonce while the edge consistently supplies static headers.

Multiple CSP fields do not simply merge into one more permissive policy. A browser enforces each policy separately, which generally produces a stricter result; operators still struggle to infer the real intent from layered output. Inspecting the final production response is more reliable than testing only a framework configuration object.

Examples

Build a baseline policy

This pure function creates a minimal baseline for an ordinary HTML response. It deliberately omits includeSubDomains and preload because those options require an audit of the whole domain namespace first. A real application must add CSP sources from its resource inventory and define separate policies for APIs, downloads, and static assets.

frame-ancestors 'none' prevents every page from embedding this page; pass reviewed, complete origins when same-origin or partner embedding is a real requirement. The function emits HSTS only when https is true, but the deployment layer must also ensure it appears only on genuine HTTPS responses and interprets a trusted proxy’s forwarded protocol correctly.

Generate a CSP nonce per response

This render function uses Node 24’s cryptographic random source to create a 128-bit nonce. It prints security properties rather than the random secret, so repeated runs still produce stable, reviewable output. The example also escapes < in the message, showing that nonce authorization and data safety are separate boundaries.

import { randomBytes } from 'node:crypto';

function renderPage(message) {
  const nonce = randomBytes(16).toString('base64');
  const policy = [
    "default-src 'self'",
    `script-src 'nonce-${nonce}'`,
    "object-src 'none'",
    "base-uri 'none'",
  ].join('; ');

  // A nonce authorizes this element; escaping still protects the data boundary.
  const safeMessage = JSON.stringify(message).replaceAll('<', '\\u003c');
  const html = [
    '<!doctype html><meta charset="utf-8">',
    '<p id="status"></p>',
    `<script nonce="${nonce}">`,
    `document.querySelector('#status').textContent = ${safeMessage};`,
    '</script>',
  ].join('\n');
  return { nonce, policy, html };
}

const first = renderPage('</script><script>alert(1)</script>');
const second = renderPage('ready');
console.log('nonce bytes', Buffer.from(first.nonce, 'base64').length);
console.log('policy matches markup', first.policy.includes(`'nonce-${first.nonce}'`) && first.html.includes(`nonce="${first.nonce}"`));
console.log('changes per response', first.nonce !== second.nonce);
console.log('message escaped', first.html.includes('\\u003c/script>'));

nonce bytes 16
policy matches markup true
changes per response true
message escaped true

A production template must not fix the nonce in a build artifact, process global, or long-lived cached HTML. If a CDN caches a page with a nonce, the policy header and HTML must belong to the same cached object, and an attacker must not be able to predict that object’s nonce. HTML containing user data usually needs tighter cache rules as well.

Audit every response path

This test applies common policy before route selection, then requests a success and a not-found path. It proves that both responses carry the target fields, but it does not claim that a local HTTP service enforces HSTS or full browser policy; follow raw-header inspection with real-browser tests.

import { createServer } from 'node:http';

const secureHeaders = {
  'Content-Security-Policy': "default-src 'self'; object-src 'none'; frame-ancestors 'none'",
  'Referrer-Policy': 'strict-origin-when-cross-origin',
  'X-Content-Type-Options': 'nosniff',
  'Permissions-Policy': 'camera=(), microphone=(), geolocation=()',
};
const required = Object.keys(secureHeaders).map((name) => name.toLowerCase());

const server = createServer((request, response) => {
  for (const [name, value] of Object.entries(secureHeaders)) {
    response.setHeader(name, value);
  }
  if (request.url === '/ok') {
    response.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
    response.end('ready');
    return;
  }
  response.writeHead(404, { 'Content-Type': 'text/plain; charset=utf-8' });
  response.end('not found');
});

server.listen(0, '127.0.0.1', async () => {
  const { port } = server.address();
  for (const path of ['/ok', '/missing']) {
    const response = await fetch(`http://127.0.0.1:${port}${path}`);
    const missing = required.filter((name) => !response.headers.has(name));
    console.log(path, response.status, `missing=${missing.join(',') || 'none'}`);
  }
  server.close();
});

/ok 200 missing=none
/missing 404 missing=none

Deployment tests should also trigger authentication failure, oversized requests, rate limits, and upstream failures. A gateway may generate these responses without running application middleware at all. If the frontend must read an error status, inspect the corresponding CORS policy too, while keeping CORS distinct from the security response headers covered here.

Pitfalls

Trading policy for “compatibility”

Fix: derive the policy from a resource inventory observed in the browser. Prefer controlled external script files; use a per-response nonce or reviewed hash when inline script is necessary. Record an owner, purpose, resource type, and removal condition for every new source, and observe it in report-only mode before enforcing it.

Reusing a nonce or changing one side

Fix: create an unpredictable nonce while rendering each response and carry it through one request context to both the policy builder and template. Test that the value changes and that both sides match exactly. Audit page caching so one personalized response and its nonce cannot be reused for other requests.

Expanding HSTS too early

Fix: inventory every subdomain and certificate-renewal path, verify with a short max-age, then increase it gradually. Add includeSubDomains and submit for preload only when the namespace meets the requirements and the team accepts the slower removal process. A rollback header takes effect only after the browser receives it again over HTTPS.

Protecting only successful responses

Fix: set static headers in a common layer that covers every response, with an explicit interface for dynamic nonces. Trigger important application and infrastructure status codes one by one, inspect the final fields over raw HTTP, then confirm CSP, framing, and permission behavior in a browser.

Confusing framing directions

Fix: use frame-ancestors to control who may embed this page and frame-src to control what this page may load in a frame. Choose frame-ancestors 'none' when no embedding is needed and list exact origins for partners. You may retain compatible X-Frame-Options, but it must not contradict the CSP intent.

Keeping obsolete headers alive

Fix: remove legacy fields you cannot explain with target-browser support evidence. Use CSP for script execution, frame-ancestors for embedding origins, and only DENY or SAMEORIGIN compatibility forms of X-Frame-Options. Test feature behavior in browsers instead of assigning a score from the number of headers.

Further reading

• MDN: Content Security Policy
• MDN: Strict-Transport-Security
• MDN: X-Content-Type-Options
• MDN: Permissions Policy
• W3C: Content Security Policy Level 3