Security Headers Checker
Check any website's HTTP security headers in seconds. Get a clear pass/fail for HSTS, Content-Security-Policy, and more — with copy-paste fixes.
This tool reads publicly available configuration (HTTP response headers). It performs no intrusive testing. Only scan domains you own or are authorized to assess.
What are HTTP security headers?
HTTP security headers are instructions a web server sends with every response telling the browser how to behave more safely — for example, to refuse to load the page in a frame, to only connect over HTTPS, or to restrict which scripts may run.
They are one of the cheapest, highest-leverage hardening steps available: most are a single line of server configuration, and together they shut down whole classes of attack such as clickjacking, protocol downgrade (SSL-strip), MIME-sniffing, and a large share of cross-site scripting (XSS) impact.
This checker reads the headers your site already returns on its homepage — exactly what any visitor's browser sees — and grades each one against current best practice. It performs no intrusive testing; it is equivalent to a single curl request.
How to fix missing security headers
Most findings are resolved by adding a response header in your web server, CDN, or application framework. Add them incrementally and re-test:
- Strict-Transport-Security: max-age=63072000; includeSubDomains; preload — forces HTTPS on every future visit.
- Content-Security-Policy: start from default-src 'self' and widen deliberately — the single biggest XSS mitigation.
- X-Content-Type-Options: nosniff — stops MIME-type confusion attacks.
- X-Frame-Options: DENY (or a CSP frame-ancestors directive) — prevents clickjacking.
- Referrer-Policy: strict-origin-when-cross-origin — stops full URLs leaking to third parties.
Common SSL problems and where to fix them
- 'unsafe-inline' in script-src — how to remove it →
- CSP is blocking my site — fix without disabling →
- HSTS: what it does and how to enable it →
- X-Content-Type-Options: nosniff, explained →
- Clickjacking and X-Frame-Options →
- Set the headers in nginx →
- Set the headers in Apache →
- Set the headers at Cloudflare →
New to SSL/TLS errors? Start with the complete guide to SSL/TLS errors →
Frequently asked questions
Is this security headers checker free?
Yes. It is completely free and open — no account, no email, no signup. Enter a domain and get the result immediately.
Does the test perform any intrusive scanning?
No. It only reads the HTTP response headers your site already returns on a normal request — the same thing any browser receives. It is passive and equivalent to a single curl request.
Which security headers does it check?
Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy, plus cookie flags and HTTPS-redirect behaviour.
Why did my site get a warning for a missing header?
Each missing header removes a layer of defense. The result explains what each one protects against and gives the exact header value to add. Fix them, then re-scan to confirm.
How do I test whether HSTS is working on my site?
Enter your domain above: the result shows whether Strict-Transport-Security is sent, its max-age in both seconds and years, and whether includeSubDomains and preload are present. Three things are worth checking beyond mere presence. A max-age under six months is too short to be useful and disqualifies you from preload, which needs at least one year. includeSubDomains locks every subdomain to HTTPS, so confirm none of them still needs plain HTTP before enabling it. And the header only counts on an HTTPS response — if your site sends HSTS over plain HTTP, browsers ignore it entirely. From a terminal the equivalent is curl -sI https://yourdomain.com | grep -i strict-transport. Note that a browser that has already seen your HSTS header will keep enforcing it from its own cache, so testing in a normal browser window can show HTTPS working even after you remove the header from the server.
How do I check the nosniff header?
The result above lists X-Content-Type-Options as either present with the value nosniff, or missing. There is only one valid value, so there is nothing to tune: either the header is there or it is not. It matters most for any site that serves files users uploaded, because sniffing is what lets a file declared as an image be reinterpreted and executed as script. The one case where it can break something legitimate is a download endpoint that relies on the browser guessing the type because the server sends a wrong or generic Content-Type — the fix there is to send the correct type, not to drop the header.
The header is set in my app but this checker says it is missing. Why?
Almost always because something in front of your application is answering the request. A CDN, reverse proxy or load balancer terminates the connection and returns its own response headers, and if the header is configured only in the application it never reaches the browser. This checker reads what is actually on the wire, which is what the browser sees, so a disagreement between it and your config file is usually the checker being right. Check the layer closest to the visitor first. The other common cause is setting the header on one path only — headers must be sent on every response, including redirects and error pages, and a redirect from the apex to www is a frequent gap.