Security Headers Checker

Enter any site URL to check whether key security headers such as HSTS, CSP, and X-Frame-Options are properly configured. See which headers are missing or weak, along with tips for fixing each one.

Tips

  • This tool fetches the target URL server-side, so it can check any site's headers without hitting the browser's CORS restrictions.
  • A longer HSTS max-age is generally safer, but if you're planning to change your certificate setup, test with a shorter value first before rolling it out to production.
  • Combine this with the sibling CSP Validator (dev.server.csp_validator) tool to check the actual syntax of your Content-Security-Policy in detail.
  • This tool reuses the same "enter a URL, fetch it server-side" mechanism as the robots.txt checker, so it can check any publicly accessible page without authentication.
  • Check your own site periodically to make sure a CDN or reverse proxy configuration change hasn't silently dropped a security header.

Frequently Asked Questions

The functionality is similar, but Toolbase's checker lets you review results and remediation explanations in Japanese. Detailed CSP syntax checking is handled by the sibling CSP Validator tool instead.

Yes, but since HSTS is only meaningful for HTTPS connections, the HSTS item will always be diagnosed as failing on an HTTP-only site. Migrating the whole site to HTTPS should be your first priority.

The Content-Security-Policy frame-ancestors directive is currently recommended, but since some older browsers don't support it, specifying both as a double layer of defense is the common practice.

No. The request to the URL you enter happens on the fly, and the retrieved header information is never stored on the server.

Not necessarily. Permissions-Policy in particular is an optional extra layer of defense, and its priority may be lower depending on the nature of the site. We recommend improving high-impact items such as HSTS, CSP, and X-Frame-Options first.
ツールくん

Side Note — securityheaders.com and the history of clickjacking defense

Diagnosing security settings via HTTP response headers has long been dominated by securityheaders.com, built by Scott Helme. Since many overseas services only explain results and remediation in English, Toolbase built its own checker so results and explanations can be reviewed together in Japanese as an alternative in this space.

HSTS (HTTP Strict Transport Security) was standardized by the IETF as RFC 6797 in 2012. The motivation traces back to a 2009 demonstration of "SSL Stripping," an attack that exploits the brief moment when a user types a URL without https:// and the browser connects over plain HTTP first, letting an attacker rewrite the traffic. HSTS lets a browser remember "this domain must always be accessed over HTTPS," preventing downgrade attacks after the first visit.

X-Frame-Options was originally a proprietary extension header introduced by Microsoft for Internet Explorer 8 in 2009, later adopted by other browsers and becoming a de facto standard. The concern at the time was "clickjacking," where an invisible iframe is layered over a genuine-looking button so a user clicks without realizing it. Today, the industry is moving toward the more flexible frame-ancestors directive in Content-Security-Policy, but specifying both is still recommended as a fallback for older browsers that don't support it.

→ Read related trivia

→ Browse all trivia

More tools in this category