Security headers checker
Paste the HTTP response headers of your site (run curl -sI on your address and paste the output) and this page tells you which security headers are missing or weak, with a plain explanation and a corrected line for each. A web page cannot read another site's headers itself, so the pasting is needed, and nothing you paste leaves your browser.
Get the headers
Run this in Terminal (Mac, Linux) or PowerShell, with your own address, and paste everything it prints:
curl -sI https://example.com/
A web page cannot read the response headers of another site: browsers block it on purpose, and fetching the address from here would only show our own connection, not what your visitors get. That is why you paste the headers. Nothing you paste leaves this page. You can also copy them from your browser: Network tab, click the first request, Response Headers.
Paste the headers to see the result.
What it does
- •Reads the headers you paste, in any letter case, and checks the last response when you pasted a redirect chain (curl prints one block per redirect).
- •Checks Strict-Transport-Security (max-age, includeSubDomains, preload rules), Content-Security-Policy (unsafe-inline and unsafe-eval in script rules, wildcard and http: sources, missing object-src, base-uri and frame-ancestors, the default-src fallback, report-only versus enforced), X-Frame-Options against frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy, the deprecated X-XSS-Protection, and version details in Server and X-Powered-By.
- •Marks each finding Fine, Review or Fix, explains it in plain words and gives the corrected header line, then collects a block of suggested headers you can copy.
- •The rules follow the MDN header reference pages and the OWASP Secure Headers Project, checked on 2026-11-01. This page gives a pass, review or fix result for each check, not a letter grade.
What it does not do
- •It does not fetch your site. It only reads the text you paste, so it cannot see headers that differ by page, country, cookie or user agent. Check the page you care about.
- •It does not test that your policy works. A Content-Security-Policy that looks strong here can still break your pages, and one that looks fine can have gaps a header check cannot see, such as scripts allowed from a host that serves user content.
- •It does not check cookies, TLS settings, certificates or the redirect from http to https, which the HSTS preload list also asks for.
- •Headers set in HTML <meta> tags are not part of the response headers, so they are not seen.
Questions
- How do I get my site's headers?
- In a terminal run curl -sI https://your-site.example/ and paste everything it prints. Add -L to follow redirects. In a browser, open the developer tools, go to the Network tab, reload, click the first request and copy the Response Headers. Check the page you want to protect, not only the home page.
- Why can't this page just check my address for me?
- Browsers do not let one site read another site's response headers, and a request made from this page would show our connection rather than what your visitors get. Pasting the headers is also why nothing about your site is sent to us.
- What should Strict-Transport-Security be?
- A common choice is Strict-Transport-Security: max-age=31536000; includeSubDomains, which tells browsers for a year to use only https for the site and its subdomains. Add preload only if every subdomain works over https and you plan to submit the domain to the browsers' preload list, which is hard to undo.
- My Content-Security-Policy has 'unsafe-inline'. Is that bad?
- Yes, for scripts: with 'unsafe-inline' and no nonce or hash, any inline script an attacker manages to inject will run, which is the main thing a CSP is meant to stop. Moving scripts into files or adding nonces or hashes fixes it. 'unsafe-inline' in style-src is much less risky. This page flags the script case.
- Do I need both X-Frame-Options and frame-ancestors?
- frame-ancestors in your Content-Security-Policy is the modern way and wins in current browsers. X-Frame-Options (DENY or SAMEORIGIN) is still sent by many sites for very old browsers. One of them is enough; sending both is fine as long as they agree.
- Should I remove X-XSS-Protection?
- Set it to 0 or remove it. The browser filter it controlled has been dropped from current browsers, and in older ones it could itself create vulnerabilities. A good Content-Security-Policy does the job now.