Free Security Headers Checker

What are HTTP security headers?

HTTP security headers are response headers that give browsers extra instructions about how a website should be loaded, embedded, and shared with other origins. They do not replace application security, secure authentication, dependency patching, or careful server configuration, but they are an important browser safety layer. A site can have a valid SSL certificate and still miss security headers that reduce the impact of cross-site scripting, clickjacking, MIME sniffing, referrer leakage, and cross-origin data exposure.

These headers are usually set by an application framework, reverse proxy, CDN, load balancer, or hosting platform. That makes them easy to lose during migrations. A new CDN rule, framework upgrade, edge function, or redirect can accidentally remove a header from the final response even when the origin server still sends it. Checking the final HTTPS response is useful because it shows what browsers actually receive after redirects and infrastructure layers have done their work.

Website Certs checks these headers as part of the same public toolset as the SSL checker, HTTPS checker, and DNS checker. Together, those tools cover certificate health, secure endpoint behavior, DNS routing, and browser hardening signals.

For a deeper walkthrough of what each header does and how to roll them out safely, read HTTP Security Headers Explained.

What does this security headers checker test?

The checker requests the website over HTTPS, follows a limited redirect chain, captures the final response headers, and grades the result from A to F. Critical headers carry most of the score, while optional browser isolation headers add smaller signals.

• Strict-Transport-Security is checked for a strong max-age.
• Content-Security-Policy is checked for unsafe-inline and unsafe-eval.
• X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are checked for strong values.
• Permissions-Policy, COOP, CORP, and COEP are reported as additional hardening signals.

Each result includes whether the header is present, the current value if one was returned, a PASS, WARNING, or FAIL status, a short explanation, and a recommendation. The score is designed to be understandable at a glance while still giving enough detail to fix the response. The final URL, HTTP status code, response time, and redirect chain are shown because security headers should be evaluated on the page that visitors actually reach.

Why HSTS matters

Strict-Transport-Security, usually called HSTS, tells browsers to use HTTPS for future requests to a site. Once a browser has seen a valid HSTS policy, it can avoid silently falling back to insecure HTTP for that hostname. This helps protect users from downgrade attacks and accidental insecure links. A strong HSTS header includes a meaningful max-age so browsers remember the HTTPS requirement long enough to matter.

This checker passes HSTS when the header is present and the max-age is at least 15552000 seconds. Lower values receive a warning because they may be useful for testing but are weaker for production. Before adding includeSubDomains or preload, make sure every subdomain is ready for HTTPS. HSTS is powerful, and a broad policy can break old or forgotten hosts if they cannot serve HTTPS correctly.

Why Content-Security-Policy matters

Content-Security-Policy, or CSP, restricts where scripts, styles, images, frames, fonts, and other resources can load from. A good CSP can reduce the damage caused by cross-site scripting because injected code has fewer places to execute or fetch resources from. CSP is especially valuable for applications that handle sessions, dashboards, billing flows, admin tools, or user-generated content.

CSP often needs careful tuning. A strict policy may initially break inline scripts, third-party widgets, or legacy code. This checker warns when the policy contains unsafe-inline or unsafe-eval because those values weaken the protection. A practical improvement path is to start with a report-only policy, remove unsafe directives where possible, and gradually tighten script-src, object-src, base-uri, and frame-ancestors.

How X-Frame-Options prevents clickjacking

X-Frame-Options controls whether a page can be embedded in a frame. Clickjacking attacks place a real page inside another interface and trick users into clicking something they did not intend to click. Setting X-Frame-Options to DENY or SAMEORIGIN blocks many unwanted framing scenarios and is still widely used for compatibility.

Modern sites can also use the CSP frame-ancestors directive for more flexible control, but X-Frame-Options remains a clear signal and a simple defense for many applications. This checker passes DENY and SAMEORIGIN, warns on unusual values, and fails the header when it is missing.

How Referrer-Policy protects privacy

Referrer-Policy controls how much URL information the browser sends when a user navigates away from your site or loads cross-origin resources. Without a careful policy, full paths and query strings can be exposed to other sites. That can reveal campaign data, internal paths, document names, or sensitive values that should not have been placed in URLs in the first place.

The checker treats no-referrer, strict-origin, strict-origin-when-cross-origin, and same-origin as strong values. Weaker policies may still be acceptable for some analytics needs, but they deserve a review. Many modern sites choose strict-origin-when-cross-origin because it preserves useful origin-level attribution while avoiding full path leakage across origins.

How to improve your security headers

Start with the failed critical headers first. Add HSTS only after confirming that HTTPS works reliably with the HTTPS checker. Use the SSL checker to confirm the certificate matches the hostname and is not close to expiration. Use the DNS checker when a domain points through multiple providers or a CDN migration is in progress.

For application headers, configure them as close to the final response layer as possible. In many stacks that means a CDN, reverse proxy, web server, or framework middleware. Keep policies in source control when possible, and test both the apex domain and the canonical www or app hostname. If redirects are involved, check the final URL because intermediate responses may not represent what the browser uses after the page loads.

• HSTS is missing or has a short max-age, leaving downgrade protection weaker than expected.
• Content-Security-Policy allows unsafe-inline or unsafe-eval, which weakens script injection defenses.
• X-Frame-Options is missing, so pages may be easier to embed in clickjacking attacks.
• X-Content-Type-Options is missing or not set to nosniff.
• Referrer-Policy is missing or uses a weak value that can leak more URL detail than intended.
• Browser isolation headers such as COOP, CORP, and COEP are missing from apps that need them.

Related website checks

Security headers work best with healthy TLS and routing. Use the SSL checker for certificate details, the HTTPS checker for status and redirects, and the DNS checker for records that route visitors to the endpoint.