HTTP RESPONSE HEADERS

Security Headers Checker

See HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, framing protection and server exposure for a site in a single table.

Run Security headers

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What the security headers checker reviews

Browsers follow instructions that servers send in HTTP response headers. Several of those instructions reduce the impact of common web problems: forcing HTTPS, limiting which scripts run, stopping content-type guessing, trimming what is sent to other sites, limiting powerful browser features, and controlling who can embed a page. This tool fetches the landing page and reviews seven of them in one table: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, framing protection (X-Frame-Options or CSP frame-ancestors) and the Server and X-Powered-By headers.

Each row shows the value that was sent, a verdict, a severity and a short observation. Below the table are informational notes on cross-origin isolation headers and on caching.

How to read the table

Verdicts use the same rules as the full domain assessment, so the two agree.

  • Pass: the header is present and meets the check's rule, for example HSTS with at least six months of lifetime.
  • Improve: the header is missing or weak. Severity is low or medium, reflecting that these are defensive layers.
  • Informational: optional or context-dependent. Permissions-Policy and a missing Referrer-Policy fall here, because modern browsers already apply a default of strict-origin-when-cross-origin.
  • Server exposure: a Server or X-Powered-By value that includes a product version is flagged; a product name alone is not a weakness.
  • Cross-origin headers (COOP, COEP, CORP) and Cache-Control are shown for context and are not scored.

Headers are one layer, not a security score

This tool deliberately gives no letter grade or percentage. A site can send every header here and still have vulnerable code, and a site with few headers can be well built. Headers are a layer that limits the damage of certain mistakes and attacks; they do not fix an unpatched application, weak passwords or exposed services. Use the table as a checklist of low-cost hardening and prioritise by what your site actually does: a site with logins and user content benefits from CSP and framing protection more than a static brochure page.

Common problems

  • Headers set at the wrong layer: the application sends them but a CDN or proxy strips them, or the reverse.
  • Headers only on some responses: static files, error pages and API paths often bypass the middleware that adds them.
  • Duplicate headers from two layers producing conflicting values. Only the first is examined here.
  • Error or redirect landing: such responses are not judged because their headers do not represent the site.
  • Bot protection answering the scanner with a challenge page, so the real headers are never seen.

How to add headers safely

Prerequisites: know where response headers are configured (web server, application framework, CDN or load balancer), and which features of the site rely on embedding, inline script or third-party content. Risk: a strict header such as CSP, HSTS with includeSubDomains or framing denial can break legitimate features. Rollback: change one header at a time and keep the previous configuration so you can revert quickly.

  1. Add the low-risk headers first: X-Content-Type-Options: nosniff and a sensible Referrer-Policy.
  2. Add framing protection with frame-ancestors or X-Frame-Options, after checking legitimate embedders.
  3. Introduce HSTS with a short max-age and extend it gradually.
  4. Deploy CSP in report-only mode and tighten over time.
  5. Re-run this checker and verify in a browser's developer tools that headers arrive on real pages.

Limits

Only the landing page response is examined, from one location, and only the first occurrence of a repeated header. Exposure headers other than Server and X-Powered-By are not assessed. The tool identifies itself honestly and does not imitate a browser, so sites that block automated clients may show different headers to it. A pass does not mean the site is secure.

Frequently asked questions

Why is there no score or grade?

Headers are one layer among many, and a number would suggest a precision they do not have. The table shows each header and what to consider.

Which header matters most?

It depends on the site. HSTS and CSP usually have the broadest effect for sites with logins; nosniff and referrer policy are low-effort, low-risk additions.

Why is Permissions-Policy only informational?

It is optional hardening that restricts browser features, which matters mostly if you embed third-party content.

Do these headers affect search rankings?

This tool makes no ranking claims. Headers protect visitors; they are not a ranking factor we can promise.

My CDN adds headers. Will the tool see them?

Yes, it sees what arrives from the network, not how it was produced.

Why does a header show on my site in a browser but not here?

The page may serve different headers to automated clients, or other paths may differ from the landing page.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09