Which security headers should every website have?

Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Content-Security-Policy. The first four are safe to add immediately and take minutes. Content-Security-Policy is the most valuable and the most likely to break something, so deploy it in report-only mode first and read the violations before enforcing.

Do security headers affect SEO?

Not as a direct ranking factor. They matter because HTTPS is one, and because a site compromised through a preventable attack loses far more than a ranking position. They also appear in the trust signals that both people and automated systems use to assess a site.

Is there a free security headers checker?

Yes. Ours is free and needs no account for your first scan. It reports which headers are present, which are missing, and where a present header is configured in a way that undermines its own purpose.

Security27 July 20267 min read

Free security headers checker: what each header actually stops

Six headers, each defending against a specific attack. Here is what each one prevents, in the order worth adding them, and which one to deploy carefully.

By Sapun Lamichhane · Arcetis

Security headers are instructions to the browser about what it may do with your page. Each defends against a specific attack, and most take minutes to add. They are among the highest-value-per-effort changes available on a website, which is why their absence is so common and so avoidable.

Strict-Transport-Security

Tells the browser to use HTTPS for your domain and never attempt HTTP again. It closes the window in which a redirect from HTTP can be intercepted — the moment before your redirect takes effect.

The caveat is real: once sent with includeSubDomains, every subdomain must support HTTPS for the duration of the max-age. Be certain before you set a long one.

X-Content-Type-Options

One value, nosniff. It stops the browser second-guessing your declared content types. Without it, a file you serve as text can be interpreted as a script, which is how user-uploaded content becomes a code execution path.

Referrer-Policy

Controls how much URL information travels with outbound requests. Without it, the full URL of the page a user was on — including any path segments you would rather not share — is sent to every third party your page contacts.

Permissions-Policy

Declares which browser features your page may use. Denying camera, microphone, geolocation and the rest you do not need means an injected script cannot request them either.

Content-Security-Policy

The most valuable and the one to approach carefully. It declares which sources may load scripts, styles and other resources, and it is the strongest single defence against cross-site scripting available.

It is also the one most likely to break your site, because a policy strict enough to be worth having will block something you forgot about. Deploy it as Content-Security-Policy-Report-Only first, collect violations for a week, and enforce once the reports are quiet.

A policy so strict it breaks your own product is not a security win. We shipped one that blocked our own sign-in, and then one that blocked our own API.

The order worth doing it in

1X-Content-Type-Options — one line, no risk.
2Referrer-Policy — one line, no risk.
3Permissions-Policy — deny what you do not use.
4Strict-Transport-Security — after confirming every subdomain does HTTPS.
5Content-Security-Policy — report-only first, always.

What free means here

Our security headers checker is free, with no account needed for your first scan. It reports missing headers and, more usefully, headers that are present but configured in ways that defeat their own purpose — a max-age of 0, or a policy permitting everything it was meant to restrict.