Security Headers Checker: Grade Your HTTP Response Headers

How to use the security headers checker

1. Run curl -I https://example.com or open your browser developer tools to the Network tab and copy the response headers.
2. Paste the raw headers into the text area above.
3. Review the overall grade and the individual grades for each of the six core security headers.
4. Read the note beside each grade to see what is missing or misconfigured and what value to apply.

How the grading works

This security headers checker assigns a letter grade from A to F to each of six headers, then combines them into an overall grade. The overall grade is a weighted average of the six grades (A = 4 points down to F = 0): Content-Security-Policy counts three times, Strict-Transport-Security twice and the other four once. The result row also names your weakest header. This is a simple rubric written for this tool, not the scoring used by securityheaders.com or Mozilla Observatory, so the letters will not always match theirs.

• HSTS: A for a max-age of at least 31536000 (one year) with includeSubDomains; preload is noted but not required. B without includeSubDomains, C for at least six months, D for a shorter positive max-age, F if missing or zero.
• CSP: F if missing. C if there is no script-src or default-src. D if the script sources (or object sources) contain 'unsafe-inline' without a nonce, hash or 'strict-dynamic', a * wildcard, data:, or a bare https: or http:. B if the only weakness is 'unsafe-eval'. Otherwise A. For a full review use the CSP evaluator.
• X-Frame-Options: A for DENY or SAMEORIGIN, and also A when the header is missing but CSP has frame-ancestors. C for the obsolete ALLOW-FROM. F if missing without frame-ancestors, or invalid.
• X-Content-Type-Options: A when the value is exactly nosniff, otherwise F.
• Referrer-Policy: A for no-referrer, same-origin, strict-origin or strict-origin-when-cross-origin. B for origin. C for no-referrer-when-downgrade, origin-when-cross-origin or a value no browser recognizes. F for unsafe-url or a missing header. In a comma-separated list the last recognized value is used, as browsers do.
• Permissions-Policy: A when it looks like a valid policy such as geolocation=(), C if it is present but malformed, F if missing.

Reference table of recommended values

The following table shows the ideal configuration for each header when aiming for an A grade.

If you need help building a policy from scratch, use the content security policy generator or the hsts checker tool to verify your HSTS setup.

Why these six headers matter

HTTP response headers instruct the browser on how to handle content and connections. Without them, browsers fall back to permissive defaults that leave users vulnerable to cross-site scripting, clickjacking and protocol downgrade attacks.

HSTS forces the browser to always use HTTPS, preventing man-in-the-middle downgrades. CSP restricts where scripts and resources can load from, neutralizing many injection attacks. X-Frame-Options stops other sites from embedding your pages in iframes, blocking clickjacking. X-Content-Type-Options prevents MIME-type sniffing, which can lead to executing malicious files disguised as harmless types. Referrer-Policy controls how much URL information leaks to third parties, and Permissions-Policy disables access to sensitive browser APIs like the camera or geolocation by default.

Common mistakes and edge cases

A frequent error is setting a very short HSTS max-age during testing and forgetting to increase it before production. Browsers cache the HSTS policy, but a short duration leaves a large window for downgrade attacks.

Another issue is deploying a CSP that includes 'unsafe-inline' to quickly fix broken JavaScript. While this stops the page from breaking, it completely defeats the purpose of the CSP against cross-site scripting. Instead, migrate inline scripts to external files or use nonces and hashes.

Finally, some servers send duplicate headers instead of combining them. For example, sending two X-Frame-Options headers may cause browsers to ignore both. Always ensure your server merges directives into a single comma-separated value where applicable.

The checker reads only the headers you paste. It does not fetch your site, so it cannot see headers added by a CDN or a different path, and it does not test whether your policy breaks anything in a browser.

Extracting headers for analysis

To get the raw headers needed for this security headers checker, you can use command-line tools or browser features. With cURL, run curl -sI https://yourdomain.com to fetch only the headers without the body. In Chrome or Firefox, open Developer Tools, navigate to the Network tab, reload the page, click the main document request and view the Response Headers section.

Copy everything from that section and paste it directly into the input field. You do not need to strip out status lines like HTTP/2 200; the parser ignores lines that do not contain a colon separator. If you are auditing general formatting rather than security specifically, a standard http headers checker might also be useful.

Worked examples