How to Scan a Website's Security Headers

One URL is all you need. Point a security header scanner at any site and it fetches the real response, then scores the HTTP headers it returns. In seconds you know whether the site ships with Content-Security-Policy, HSTS and the rest, or hands every visitor an unarmored page. This guide covers why that matters, what an A-F grade means, and how a live scan differs from auditing a static config file.

Why You Should Check Security Headers

HTTP headers are the first line of defense a web server has. A Content-Security-Policy header restricts where scripts and styles load from, which blocks most stored and reflected cross-site scripting. Strict-Transport-Security forces HTTPS and kills protocol downgrade and cookie-stripping attacks. X-Frame-Options stops your pages being embedded in a clickjacking iframe on an attacker’s site.

The cost of missing headers is concrete, not theoretical. No CSP means a single injected <script> runs with full page access. No X-Frame-Options means an overlay page can sit on top of yours and capture clicks. No X-Content-Type-Options: nosniff means a browser can be tricked into executing a wrong MIME type. A scanner turns that vague risk into a specific list of what is missing, so remediation is mechanical rather than guesswork.

What an A-F Grade Means

The grade is an aggregate of the individual header checks. Each header is evaluated and weighted, then the results are rolled into a single A-to-F score that mirrors the spirit of an SSL Labs rating: A means every critical protection is present and correctly configured, while F means one or more critical headers are absent entirely. Grading is a snapshot of the response captured at scan time; a grade below C is common even on well-trafficked sites, because most headers fail on a single misconfiguration like max-age being too short or a CSP that allows unsafe inline scripts.

Treat the letter as a triage tool, not a certification. It answers “how much work is left” at a glance, and the per-header breakdown tells you exactly which lines to fix first.

Live Scan vs a Static Checklist

Scanning a live site is fundamentally different from auditing an nginx or Apache config. A static checklist tells you intent; a live scan tells you what a real browser and a real attacker actually see. The differences matter:

• Redirect chains: a header set on the initial response but not the final one is useless, and only a live scan follows the redirects.
• Transport context: HSTS is ignored over plain HTTP, so a header you configured correctly can fail the real check.
• Per-path behavior: servers often set different headers on static assets, API routes and admin paths.
• Cookie flags: whether Secure and HttpOnly are actually set is only observable on a live response.
• Middleware: a load balancer, CDN or edge function can silently strip headers you think you shipped.

A static audit cannot catch any of these. That is why an HTTP header audit should be run against the production URL, not the config file.

When you do scan, read the per-header verdicts, not just the letter grade. A CSP that is present but uses unsafe-inline is materially weaker than one that does not; an HSTS max-age under six months will not get you onto the HSTS preload list; a header that appears only on the www host leaves the apex vulnerable. The scanner’s value is that it names each of these failures precisely, so the remediation list reads like a diff of your configuration rather than a vague security recommendation.

The Headers That Matter Most

Run the scan once to get a baseline, fix the failing headers, then re-scan to confirm the grade moved. Re-run it on a schedule or after any deploy that touches headers, TLS, or edge configuration.

Next step: run the free security header scanner against your own site, fix the critical (F) items first, and re-scan until you hold an A.

More posts →