Security Headers Check

// What is tested

• A single GET request to the URL, following redirects one hop at a time with every hop re-validated against the same target rules.
• Seven response headers, weighted: Content-Security-Policy (25), Strict-Transport-Security (20), X-Frame-Options or CSP frame-ancestors (20), X-Content-Type-Options (15), Referrer-Policy (10), Permissions-Policy (5) and Cross-Origin-Opener-Policy (5).
• Partial credit where a header is present but weak — an HSTS max-age below the recommended minimum, a CSP containing unsafe directives, or a Referrer-Policy that leaks full URLs — scores lower than a sound value rather than zero.
• Version-disclosing headers: Server, X-Powered-By, X-AspNet-Version and X-Generator. Each costs five points.
• The final score, floored at zero, maps to a letter grade: A+ at 95, A at 85, B at 70, C at 55, D at 40.

// Data sources

The site's own response headers

Read directly from a live request. Nothing is cached and no third-party rating service is involved.

// Limits

• The weights and thresholds are ours. They reflect current OWASP guidance on which headers carry the most risk reduction, but another checker applying different weights will reasonably return a different grade for the same site.
• One URL is checked. Headers are frequently set per-route, so a clean home page says nothing about an API path or an admin area.
• Headers are a small part of a site's security. A perfect grade here is entirely compatible with SQL injection, broken authentication or an exposed database.
• Header presence is scored, not correctness of intent. A CSP can be syntactically sound, score well and still permit exactly the injection it was written to stop.
• http and https only, on ports 80, 443 and 8443. Internal hostnames and private addresses are refused, and every redirect hop is re-checked against the same rules.