--- title: Free Security Headers Checker description: Audit the HTTP security headers a URL sends — Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — with the value of each and what a missing one leaves open. The same request a browser makes, from a real probe location. canonical: https://watchfor.io/security-headers-checker --- [Back to all free tools](/free-tools) # Security Headers Checker Audit the HTTP security headers a URL sends — Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — with the value of each and what a missing one leaves open. The same request a browser makes, from a real probe location. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Security Headers Checker ? HTTP security headers are instructions a site gives the browser about what it may and may not do with the page: only ever use HTTPS for this host ( Strict-Transport-Security ), only run scripts from these origins ( Content-Security-Policy ), don't let other sites frame me ( X-Frame-Options , or CSP frame-ancestors ), don't guess content types ( X-Content-Type-Options ), don't leak my URLs to third parties ( Referrer-Policy ), and don't let this page use the camera ( Permissions-Policy ). Each one closes a class of attack that the application code can't close on its own. This tool fetches a URL from a real probe location and audits those headers: which are present, their exact values, and what each missing one leaves open. It's the same response a browser gets — including whatever a CDN or reverse proxy added or stripped on the way — so it tells you what users actually receive rather than what the application config says. ## How it works One request, read the way a browser reads it: - 1 GET the URL — From the probe location nearest you (or the one you pick), following redirects by default, so the headers are from the final page rather than from a 301. - 2 Extract the security set — Seven headers are audited: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the legacy X-XSS-Protection. Every other response header is listed below them. - 3 Explain each one — Present headers show their value; missing ones show what the absence permits. The full header list is there for anything else — Server version leaks, cookies without Secure , cache headers on private pages. For HSTS specifically — max-age, includeSubDomains and preload eligibility — the HSTS checker goes a level deeper. ## When you'd use it ### Before a penetration test Missing security headers are the first page of every pentest report. Add them first and let the testers spend their time on findings that need thought. ### After adding a CDN or proxy Cloudflare, a WAF or an nginx reverse proxy can add, override or drop headers. Check the public URL after the change, not the origin. ### Verifying a CSP rollout Content-Security-Policy is easy to get wrong and hard to see. Confirm the header is the one you meant — report-only vs enforcing, the right script-src — on the pages that matter. ### Checking a vendor-hosted page The marketing site on a page builder, the docs on a SaaS, the status page. You don't control their config but you're the one named on the page. Know what they send. ## Reading the result ### Strict-Transport-Security max-age=31536000; includeSubDomains; preload is the target. Anything shorter than a year isn't preload-eligible; missing means the first visit can be hijacked over HTTP. ### Content-Security-Policy The most powerful and the most work. A policy with 'unsafe-inline' in script-src blocks little; a strict nonce- or hash-based one blocks most XSS. Content-Security-Policy-Report-Only observes without enforcing — useful while rolling out, not protection. ### X-Frame-Options and frame-ancestors DENY or SAMEORIGIN stops clickjacking. CSP's frame-ancestors supersedes it and allows specific origins; send both for older browsers. ### The rest X-Content-Type-Options: nosniff (always). Referrer-Policy: strict-origin-when-cross-origin or stricter. Permissions-Policy disabling features you don't use. X-XSS-Protection: 0 if sent at all — the filter it toggles caused more harm than good. ## Check it yourself curl -sI https://example.com | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy' -I sends HEAD; some servers return different headers to GET. Use -s -o /dev/null -D - for a GET. ## Common pitfalls ### Setting headers only on HTML APIs, error pages and static assets served by a different path or a different service often miss them. The browser applies HSTS from any response; CSP matters on every document. ### A CSP that breaks the site Deploy in Report-Only first, collect violations, then enforce. An enforcing policy that blocks your own analytics or payment iframe is a customer-facing outage. ### Duplicate or conflicting headers The app sets one CSP, the proxy adds another; the browser applies both, intersected — usually stricter than either author intended. The full header list shows duplicates. ## Run Security Headers Checker on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions Which security headers should every site have? Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy and Permissions-Policy. Six headers, one afternoon, most of a pentest's low-hanging findings gone. Are security headers a ranking factor? Not directly. HTTPS is; HSTS makes HTTPS stick. Their value is in what they prevent, not in search position. Where do I set them? Wherever the response is assembled last: the web server config (nginx add_header , Apache Header set ), the framework's middleware, or the CDN's response-header rules. Then verify on the public URL. What does a good Content-Security-Policy look like? default-src 'self'; script-src 'self' 'nonce-…'; object-src 'none'; base-uri 'self'; frame-ancestors 'none' is a strong starting shape. Add the specific origins you load from; avoid 'unsafe-inline' and wildcards in script-src . Is X-XSS-Protection still needed? No. Modern browsers removed the filter; where it existed it introduced vulnerabilities. Send 0 for legacy browsers or omit it. CSP is the real XSS defence. Why does my API need security headers? HSTS still applies (browsers learn it from any response on the host), nosniff prevents JSON being interpreted as HTML in odd cases, and a CSP of default-src 'none' on API responses stops a reflected response being rendered. Cheap to add, no downside. ## Related web tools - [HTTP HeadersInspect response headers, status, redirect chain and security headers.](/http-header-checker) - [MCP Server CheckerTest a Model Context Protocol server: initialize handshake, protocol version, capabilities and the full tool inventory.](/mcp-server-checker) - [SSL Certificate CheckInspect certificate validity, expiry, SANs, issuer and chain trust.](/ssl-checker) - [SSL/TLS GradeGrade a server's TLS config A+ to F — protocols, ciphers, forward secrecy, post-quantum, HSTS and certificate, with the exact reasons.](/ssl-grade-checker) --- Canonical page: https://watchfor.io/security-headers-checker · Site guide: https://watchfor.io/llms.txt