Security Headers Checker: Grade Your HTTP Headers

HTTP security headers are response headers a server sends with a page to tell the browser how to treat it: which sources may load scripts (Content-Security-Policy), that the site must use HTTPS (Strict-Transport-Security), whether other sites may frame it, how much referrer information to send and which browser features to allow. They add a layer of defence in the browser and do not replace fixing the underlying bugs.

A page running in your browser cannot read another site’s response headers, because browsers block cross-origin reads (CORS) unless the other site opts in. A tool that takes a URL has to make the request from a server. We chose not to fetch third-party URLs from our server, since that needs a strict guard against server-side request forgery. Pasting the output of curl -sI keeps the check private: nothing leaves your browser.

In a terminal run curl -sI https://your-site.example (add -L to follow redirects; the checker scores the last response). In a browser, open developer tools, the Network tab, select the document request and copy the response headers. Check the page you care about, since headers can differ by path.

Most guidance starts with Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, a framing control (CSP frame-ancestors or X-Frame-Options), Referrer-Policy and Permissions-Policy. The OWASP Secure Headers Project maintains a list of recommended response headers. The cross-origin family (COOP, COEP, CORP) matters most for sites that handle sensitive sessions or need cross-origin isolation.

The preload list is a list of domains that browsers treat as HTTPS-only before ever visiting them. MDN says the header must have max-age of at least 31536000 (one year), includeSubDomains and preload to be eligible, and that preloading is not part of the HSTS specification. Check that every subdomain serves HTTPS first, because it is hard to undo.

No. MDN lists X-XSS-Protection as deprecated and non-standard. Rely on a Content-Security-Policy instead. If a scanner flags its absence, that is not a gap in modern browsers.

Each check has a points weight chosen by PlayCISO: Content-Security-Policy 25, Strict-Transport-Security 15, X-Content-Type-Options 10, clickjacking protection 10, Referrer-Policy 8, cookie flags 8 (only when a cookie is set), Permissions-Policy 7, COOP 5, Cache-Control 5, CORP 3, COEP 3, technology disclosure 3. The score is points earned over points possible. It is a teaching grade and is not the grade of any other scanner, so the two will not match.

They can. A strict Content-Security-Policy blocks inline scripts and unlisted hosts, and Cross-Origin-Embedder-Policy blocks cross-origin resources that do not opt in. Start CSP as Content-Security-Policy-Report-Only, read the reports, then enforce. Roll out HSTS with a short max-age first if you are unsure every subdomain supports HTTPS.

No. Analysis runs in your browser with no network calls, and PlayCISO does not receive the headers. Response headers rarely hold secrets, but cookie values can: remove session cookie values before sharing a paste anywhere.