HTTPS and security headers check
Security headers tell browsers how to protect your visitors: always use HTTPS, which scripts may run, and whether your pages may be framed by other sites.
What this check tells you
It requests your homepage over HTTPS and HTTP and reports whether HTTPS is enforced, and which browser security headers the final response sets, with each header's exact value as evidence.
Who it's for
Site owners and developers adding or reviewing security headers: after a hosting move, a CDN change, or a new plugin or framework that might have dropped them.
What you enter, and what happens
Your website address. The scanner sends ordinary GET requests to https:// and http:// versions of the homepage, follows at most 5 redirects (checking each hop is a public address), and reads the headers and the first 512 KiB of the HTML. Cookie values are never recorded, only their flags.
The headers we look at
- Strict-Transport-Security (HSTS) makes browsers use HTTPS for your site even if someone types or links to http://.
- Content-Security-Policy limits which scripts can run, which is your main defence if an injected script ever reaches a page.
- X-Frame-Options / frame-ancestors stop other sites from loading your pages in an invisible frame (clickjacking).
- X-Content-Type-Options: nosniff stops browsers from guessing file types.
- Referrer-Policy and Permissions-Policy limit what leaks to other sites and which browser features pages may use.
- Cookie flags: Secure, HttpOnly and SameSite protect session cookies.
Roll out headers safely
Test HSTS with a short max-age first. A long max-age with includeSubDomains will break any subdomain that doesn't support HTTPS. Introduce CSP as Content-Security-Policy-Report-Only first, review what it would block, then enforce it.
How to read the result
- High: HTTPS unavailable, or a redirect that downgrades visitors from HTTPS to HTTP.
- Medium: no HSTS, no Content Security Policy, no clickjacking protection, or a session cookie without
Secure. - Low and info: a short HSTS max-age, a missing Referrer-Policy or Permissions-Policy, or version numbers in headers.
Limits
Only the homepage response is checked. Other pages can send different headers (verified owners get a weekly check of key pages). A CSP set in a <meta> tag isn't evaluated, and cookies set by JavaScript or on other pages aren't seen. A header being present doesn't prove the policy is a good one: the CSP check flags 'unsafe-inline' and 'unsafe-eval', but it isn't a full CSP review.
Questions
Which security header should I add first?
Usually HSTS (after confirming every page works over HTTPS), then X-Content-Type-Options: nosniff and clickjacking protection, which rarely break anything. Add a Content Security Policy last, in report-only mode first.
Why does the check say HSTS is missing when my site redirects to HTTPS?
A redirect protects only the visitors who arrive on HTTP and are redirected. HSTS tells the browser to use HTTPS from the start next time, so the first request can't be intercepted. They do different jobs, and you want both.
Can I set these headers on Cloudflare or my host instead of in my code?
Yes. Most CDNs and hosts let you add response headers. The check sees whatever reaches the browser, wherever it was set.
Related: SSL/TLS certificate check · all header checks in detail · all tools.
References: OWASP Secure Headers Project, MDN: Content Security Policy, RFC 6797 (HSTS).