Security Headers Checker

Two headers carry most of the value. Strict-Transport-Security forces every future visit onto HTTPS, closing the window where a first plain-HTTP request can be intercepted. A Content-Security-Policy restricts where scripts may load from, which is the strongest practical defence against cross-site scripting — but only if it does not allow unsafe-inline, which re-opens the door it was meant to close. Deploy CSP in report-only mode first and read the violation reports, because a strict policy applied blind will break your own analytics and widgets. The rest are cheap hardening: nosniff stops a browser guessing that an uploaded file is a script, framing controls prevent clickjacking, and removing version numbers from Server and X-Powered-By stops advertising exactly which exploits to try.

Each check carries a weight reflecting its real impact — CSP 25, HSTS 20, framing and content-type 10 each, and so on. A pass earns full weight, a warning half, a fail nothing. The total is expressed as a percentage and mapped to a letter grade.

This grades headers only. It cannot tell you whether your application validates input, patches its dependencies, or handles authentication safely — a site can score an A here and still be trivially exploitable. It also checks a single response, so headers that vary by route or by content type are not covered, and it cannot verify that a Content-Security-Policy is actually appropriate for the scripts your page loads.

A site with HSTS, nosniff, X-Frame-Options and a Referrer-Policy but no Content-Security-Policy and a version-disclosing Server header scores in the C range — solid basics, but missing the header that matters most.

1. Run “curl -I https://yoursite.com”, or copy the response headers from your browser’s Network tab.
2. Paste them into the box.
3. Work through anything marked with a cross first, then the warnings.
4. Re-check after deploying to confirm the change landed.

• Shipping a Content-Security-Policy containing unsafe-inline and assuming you are protected.
• Setting HSTS with a very short max-age, which provides little protection.
• Enabling HSTS with includeSubDomains before every subdomain supports HTTPS.
• Treating a good header grade as evidence the application itself is secure.

The Security Headers Checker grades a set of HTTP response headers against eight checks covering transport security, content policy, framing, referrer leakage, permissions and version disclosure. Each check returns a pass, warning or fail with specific advice, and the whole set is scored into a letter grade.

Developers and site owners hardening a site, and anyone preparing for a security review.

• Weighted scoring, so missing CSP costs more than missing a minor header.
• Recognises that CSP frame-ancestors supersedes X-Frame-Options.
• Flags a CSP weakened by unsafe-inline rather than passing it blindly.
• Works on pasted headers, so staging and authenticated pages can be checked.

• Auditing a site before launch.
• Checking headers on a staging environment that is not publicly reachable.
• Preparing evidence for a security questionnaire.
• Confirming a header change actually took effect.