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.
Diagnosing the security headers of a live site
Enter a URL and the server fetches that site, retrieves its response headers and judges how HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are configured. It separates what is missing from what is present but weak, and explains in each case what the problem would be.
**What is worth keeping in mind here is that a header being present and a header being effective are two different things.** HSTS may well be set, for instance, yet a short `max-age` leaves too brief a window in which the browser enforces HTTPS, so the protection in practice is thin. That is why this tool distinguishes a pass from a warning. **The other point is that the headers that come back were not necessarily added by the origin server.** A CDN or reverse proxy may be inserting them along the way, in which case the place to correct the configuration changes too. What the diagnosis shows is the state visible from outside; it cannot tell you which layer put it there.
How to use it
- Enter the URL to examine Give a publicly reachable URL beginning with `https://`.
- Run the check **Destinations unreachable from outside, such as private IP addresses, are refused as a safety measure.**
- Read the verdicts They come in three grades, pass, warning and fail, where a warning means present but weak.
- Use the notes to put things right Each entry carries an explanation of what is wrong, which lets you set your priorities.
Tips for getting more out of it
- 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 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.
Where it comes in useful
Making a final check before launch
Just before release you can confirm from outside that the headers you intended are really being returned.
Taking a lead from other sites
**Seeing how far comparable sites have gone gives you a yardstick for your own standard.**
Comparing before and after a change
Re-run the check once a header has been added to confirm that it has taken effect.
Inspecting a site you have taken over
**It suits the stocktaking that follows a handover**, giving you a list of what is missing.
Terms for security headers
- HSTS
- A header compelling access over HTTPS rather than HTTP. **Unless `max-age` runs to a year or more, the protection does not last long enough.**
- X-Content-Type-Options
- Setting `nosniff` stops the browser guessing a MIME type from the content, which prevents a file being executed as something it is not.
- X-Frame-Options
- A header refusing to let your site be embedded in a frame. **In newer policies CSP's `frame-ancestors` takes on the same role.**
- Content-Security-Policy
- The mechanism restricting where loadable resources may come from. It is the centrepiece of the defence against XSS.
- Referrer-Policy
- A header deciding how much of the referring URL is handed over when a visitor moves to another site.
- Permissions-Policy
- A header controlling which origins may use features such as the camera, the microphone and location.
Frequently Asked Questions
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.