Security headers checklist 2026: what actually matters

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-inline defeats 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 once a week of traffic goes through without a redirect problem.
A frame-blocking directive: stops your pages from being embedded in another site's iframe for clickjacking. CSP's frame-ancestors directive supersedes the older X-Frame-Options header in every current browser and gives finer control (specific origins, not just same-origin or deny), so set frame-ancestors if you are already setting CSP, and keep X-Frame-Options alongside 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, for example, 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 would not 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 do not need a third-party grader for a first look. This returns exactly what your server sends, nothing more:

Anything missing from that output is a header your server simply is not sending, on this request at least. Run it against both the root domain and a couple of interior pages, since some setups apply security headers inconsistently, correctly configured on the homepage and quietly absent everywhere a CDN rule or reverse-proxy config does not 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, Scott Helme, 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 at 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 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 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. The findings feed the same composite Site Score as the rest of the technical checks, so a dropped header reads as one finding worth investigating alongside everything else that changed, not a separate manual audit you have to remember to schedule.

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.