Skip to content

The five headers that fix most of a failed scan.

Most failed security scans trace back to the same five missing response headers. Each one is a single line of server config. What they do, what to set, and the one that needs care.

Server faceplate with green status LEDs
Five checks. Each one is one line of config.

Why headers matter

Response headers are instructions to the browser. They are the only way to switch on protections the browser already ships: script-loading rules, HTTPS enforcement, content-type discipline, framing rules, referrer hygiene. No new code, no new vendor - one line each in your server or CDN config, and the protection runs on every visitor's machine.

That is why scanners weight them so heavily, ours included. Missing headers are the cheapest real risk reduction available to almost every site.

The five that matter, in order of impact

1 - Content-Security-Policy

Controls what the page is allowed to load and execute. A solid CSP is the single strongest browser-side defense against injected scripts, because injected code that violates the policy simply does not run.

It is also the one header you should not paste from a blog - including this one. Start in report-only mode, watch what your real pages load for a week, then enforce:

Content-Security-Policy-Report-Only: default-src 'self'

Tighten from there. When the console stays quiet, drop the -Report-Only.

2 - Strict-Transport-Security

Tells the browser to refuse plain HTTP for your domain, closing the downgrade window entirely. One line:

Strict-Transport-Security: max-age=31536000; includeSubDomains

This one has a real footgun around subdomains and preload - it gets its own field note.

3 - X-Content-Type-Options

nosniff stops the browser from guessing content types. Without it, a file you serve as harmless text can be re-interpreted as executable script. There is no legitimate reason to omit this header in 2026:

X-Content-Type-Options: nosniff

4 - frame-ancestors (clickjacking)

Decides who may put your site in an iframe. If nobody should, say so - it ends clickjacking as a class:

Content-Security-Policy: frame-ancestors 'none'

Keep the legacy X-Frame-Options: DENY alongside it for older browsers; the CSP directive wins wherever both are understood.

5 - Referrer-Policy

Controls how much of your URLs leak to other sites when users click away. Path and query strings can carry tokens, order IDs, internal structure. The modern default is sensible - make it explicit so a proxy or legacy setting cannot widen it:

Referrer-Policy: strict-origin-when-cross-origin

What to skip

  • X-XSS-Protection - the browser filter it controlled is gone from every modern engine; setting it does nothing useful and one legacy mode created vulnerabilities of its own. Leave it out.
  • Expect-CT - obsolete; certificate transparency is enforced by default now.
  • Header stuffing - shipping fifteen exotic headers to impress a scanner adds maintenance surface, not safety. The five above carry the weight.

Deploy checklist

  1. Add headers 2-5 today. They are safe defaults for almost every site.
  2. Start CSP in report-only. Read the violation reports for a week.
  3. Enforce CSP. Watch the console on your three most complex pages.
  4. Re-scan. The delta should be visible immediately.

Five lines of config. Most of a failed scan, fixed before lunch.

Update log (1)

2026-05-06Initial publication.

Sources + verification

Header semantics in this post follow the current published behavior of mainstream browsers and the relevant specifications (CSP Level 3, the HSTS RFC, Fetch/Referrer-Policy). Verify any value against your own stack in a staging environment before shipping; every recommendation here is testable with a curl -I and a browser console.

Keep reading

Tooling HSTS in plain English 2026-06-10 · 4 min CVE security.txt: the two-minute change that gets you warned first 2026-07-08 · 3 min AI Security How prompt injection actually works 2026-05-20 · 7 min
reading as
consumerpro