Security headers: see which ones your site sends and add the rest

Enter the address above. The checker requests the page like a browser, follows redirects to the final response, and grades HSTS, Content-Security-Policy, X-Content-Type-Options, framing protection, Referrer-Policy and Permissions-Policy against the MDN HTTP Observatory rules, plus cookie flags and version leaks. By hand, the Network panel in your browser's developer tools shows the headers of the page request.

Enter the address above. The checker reads the Strict-Transport-Security header on the final HTTPS response, flags it when it is missing, and shows whether it qualifies for the browsers' preload list: a max-age of at least 31536000 seconds (1 year), includeSubDomains and preload. By hand, open the Network panel in your browser's developer tools, click the page request and look for strict-transport-security in the response headers.

Yes. Every cookie the page sets is checked for Secure, so it is only sent over HTTPS, HttpOnly, so scripts cannot read it, and SameSite, which limits when it is sent with requests from other sites. Missing flags on session and login cookies matter most. Most platforms set them in one place, such as PHP's session settings or your framework's cookie options.

Usually because its script-src allows 'unsafe-inline', 'unsafe-eval' or any source with *, which still lets an injected script run, so the policy gives little of the protection it is meant for. Move inline scripts into files, or allow them by nonce or hash, and list only the hosts you really load scripts from. Then run the check again.

Because it names the software and its version, such as Server: Apache/2.4.41 or X-Powered-By: PHP/7.4.3, which tells attackers which known flaws to try. Hide the version with ServerTokens Prod on Apache, server_tokens off; on nginx and expose_php = Off in php.ini. It is a small hardening step; keeping the software updated matters more.

A Content-Security-Policy (CSP) is a header that lists where scripts, styles, images and frames may load from, so the browser blocks everything else. It stops most cross-site scripting, even when a plugin has a hole. Start with Content-Security-Policy-Report-Only to see what would break, then enforce it. This checker flags a missing policy and one that allows unsafe-inline scripts.

No, only the page you enter, after following its redirects. Most servers send the same headers everywhere, but apps, CDNs and plugins can set different ones per path, such as a login page or an API. Check the home page, a typical content page and anything on a different path or subdomain, such as the shop or the blog.

Not directly; Google does not rank on headers. They make a successful attack less likely, and a hacked site gets a Safe Browsing warning in Chrome and in Google's results and loses traffic fast. Most headers are one line in the web server or CDN configuration. A Content-Security-Policy takes longer; start it in report-only mode.

Yes, with no sign-up; getReport is funded by donations. The response headers are kept with the report for 12 months so the technical detail stays readable. Request headers, cookie values and anything about your visitors are never stored, and the report is not listed publicly and carries a noindex tag.