A response header does not need a code review or a deploy pipeline to matter — it is one line in the server or CDN config, and each one closes a specific, well-understood way a browser can be tricked. The checker above reads a page’s headers and explains what each one is actually for, not just whether the box is ticked.

Strict-Transport-Security (HSTS)

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

Without HSTS, the very first request a visitor’s browser makes to your domain — from a typed URL, an old bookmark, a link that still says http:// — can go out unencrypted before any redirect to HTTPS happens. That single unencrypted request is exactly what a network attacker on the same Wi-Fi is positioned to intercept. HSTS tells the browser, for the length of max-age, to never try HTTP for this domain again, closing the gap for every visit after the first.

Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self'

CSP is an allowlist for what a page may load and run. If an attacker manages to inject HTML into your page — a comment field, a search box, a compromised third-party script — a script tag they slip in still has to be permitted by the policy to execute. The most common way a CSP fails to do this job while technically being present is script-src 'unsafe-inline', which allows exactly the inline script an injection attack needs.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Some browsers, historically, would inspect a file’s bytes and decide for themselves what kind of content it was, ignoring the server’s declared Content-Type. This header turns that guessing off — the browser trusts what the server says a file is, which matters most for anything a user can upload.

X-Frame-Options and frame-ancestors

X-Frame-Options: DENY

Without this (or the equivalent frame-ancestors directive in a CSP), your page can be loaded inside an invisible or disguised frame on someone else’s site —clickjacking — where a visitor thinks they are clicking a button on the attacker’s page but the click actually lands on your page underneath.

Referrer-Policy

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

When someone navigates away from your page, the browser tells the next site where they came from — the full URL, by default, in older browsers. If your URLs ever carry a session token, a search query, or anything else in the path or query string, that travels along in the referrer to every link they click next. This header trims what is sent to other origins.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=()

Turns off browser APIs the page does not use. The value of this is mostly about third-party embeds: an ad or widget script running on your page cannot reach for the camera or the user’s location if the page itself has switched that capability off.

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

Isolates your page’s browsing context from windows opened by other origins, which closes a class of cross-window side-channel attacks. It is the newest and least urgent header on this list for most sites — worth having, rarely the thing that matters most.

Secure and HttpOnly on cookies

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict

Two flags, one job each. Secure means the cookie is only ever sent over an encrypted connection. HttpOnly means page JavaScript cannot read the cookie at all — so even a successful script injection cannot simply read the session cookie and hand it to an attacker. A session cookie missing either is the single most common way a compromised page turns into a compromised account.

What the grade means

The grade here follows the same shape as other public header scanners: missing HSTS on an HTTPS site, or serving over plain HTTP at all, is scored as critical because it affects every visitor on every page. A missing CSP, frame protection, referrer policy or an unflagged cookie are scored as warnings — real gaps, but ones an attacker needs a second foothold (an injection point, a network position) to exploit. Permissions-Policy and COOP are informational: good practice, rarely the deciding factor.

Where to actually set these

• Nginx / Apache: add_header / Header set directives in the site config.
• Vercel, Netlify, Cloudflare Pages: a headers section in the platform config file, or a CDN-level rule — no application code change needed.
• Next.js: the headers() function in next.config.js.
• Express / Node: the helmet package sets sensible defaults for most of these in a few lines.

Whichever layer you set them at, this checker reads the response as it actually arrives, so it will show you the header a CDN adds or strips on the way through — which is not always the same as what the application sent.

Frequently asked

Will these headers break my site?

CSP is the one that can, if it is stricter than what the page actually needs — a script hosted on a domain the policy does not allow will simply fail to load. Start with a report-only CSP (Content-Security-Policy-Report-Only) to see what the page uses before switching to an enforced one. The others are safe to add outright.

Do these headers help SEO?

Not directly, and Google does not grade a header checklist. HTTPS itself is a confirmed, small ranking signal; the headers here are what makes that HTTPS connection actually trustworthy rather than merely present.

Why does my site show a low grade when I use a big host?

Most hosts leave these headers to you by default — they set up TLS, not your application security policy. A managed platform being reputable does not mean it sets Content-Security-Policy for a site it knows nothing about.