Six headers cover most of the real risk: Content-Security-Policy, Strict-Transport-Security, a frame-blocking directive, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Everything past that list is diminishing returns for most sites — and the tool every checklist still points you to for grading them lost its programmatic access in April 2026.
What actually matters
-
Content-Security-Policy: controls where scripts, styles, and other resources can load from. Start in report-only mode for a week to see what it would break, then enforce with an explicit allowlist. An allowlist that includes
unsafe-inlinedefeats most of the point, since it lets an attacker's injected script run right alongside your own. -
Strict-Transport-Security (HSTS): tells the browser to only ever connect over HTTPS for the domain, closing off SSL-stripping attacks. Start with a short max-age while you confirm every subdomain actually serves HTTPS cleanly, then extend it and add
includeSubDomainsonce every subdomain checks out — HSTS only covers the exact host it's set on otherwise. Consider preload once that's stable too. -
A frame-blocking directive: stops your pages from being embedded in another site's iframe for clickjacking. CSP's
frame-ancestorsdirective supersedes the olderX-Frame-Optionsheader in every current browser and gives finer control (specific origins, not just same-origin or deny) — setframe-ancestorsif you're already setting CSP, and keepX-Frame-Optionsalongside it only for older browser compatibility. -
X-Content-Type-Options: set to
nosniff, stops a browser from guessing a file's content type and executing something as script that was served as, say, an image. - Referrer-Policy: controls how much of your URL leaks to the destination site when a visitor clicks a link — relevant for URLs containing tokens, session identifiers, or other data you wouldn't want landing in a third party's server logs.
- Permissions-Policy: restricts which browser features — camera, microphone, geolocation — an embedded page or script can use. Worth setting explicitly even if the current value is "none of this."
What to skip
X-XSS-Protection is deprecated — the browsers that respected it are gone, and modern guidance is to omit it rather than set it to a value that no longer does anything. Expect-CT is similarly obsolete now that Certificate Transparency enforcement moved into browsers directly rather than a header-driven opt-in. Public-Key-Pins (HPKP) was deprecated years ago specifically because a misconfigured pin could lock legitimate visitors out of a site with no recovery path — worth mentioning only so nobody resurrects it from an old tutorial.
Check it yourself, right now
You don't need a third-party grader for a first look. This returns exactly what your server sends, nothing more:
curl -sI https://yourdomain.com | grep -i -E "content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy"
Anything missing from that output is a header your server simply isn't sending, on this request at least. Run it against both the root domain and a couple of interior pages — some setups apply security headers inconsistently, correctly configured on the homepage and quietly absent everywhere a CDN rule or reverse-proxy config doesn't reach.
The tool everyone points you to recently lost its API
For years, the default advice in every one of these checklists has been the same: run your site through securityheaders.com, get a letter grade, done. That advice is still repeated in current 2026 guides. What changed underneath it: Probely acquired securityheaders.com from its creator in 2023, Snyk acquired Probely in 2025, and in April 2026, after a year's notice, the programmatic API was shut down. The free web scan on the site still works for a one-off manual check. What stopped working is anything built to call it automatically — on a schedule, as part of a pipeline, or as a monitor.
That distinction matters more than it sounds. A manual scan tells you your headers were correct on the day you happened to run it. Headers get lost the same way other silent defaults quietly stop being true: a reverse proxy migration drops a header nobody remembered to carry over, a CDN config change resets what the origin was sending, a new deployment pipeline skips a step the old one had. Nothing announces the regression. The site still loads. The header is just gone until the next time someone thinks to check by hand.
What continuous checking actually buys you
WebPixie's Main Page Analyzer checks 15+ security headers as part of its 50+ daily technical checks, re-scanning the homepage every day rather than on demand. A header that was correct at launch and silently disappears after an infrastructure change shows up on the next daily check instead of sitting unnoticed until someone eventually runs a manual scan again.
None of this replaces deciding what your CSP allowlist should contain or what your HSTS max-age should be — those are still judgment calls specific to your site. What it replaces is finding out those decisions silently reverted only because you happened to re-run a scanner that, as of this year, one popular option can no longer even do for you automatically.
Covered in more detail on the WebPixie blog.
