HTTP header & website security checker

HTTP response headers are key-value metadata a web server returns alongside a page or API response. They tell the browser how to cache the response, which characters to interpret it with, whether it must be served over HTTPS, whether it may be embedded in a frame, and much more. This tool fetches those headers from our server so you can see the full set that browsers usually hide from client-side JavaScript.

A reasonable starting set is Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy, and Permissions-Policy where relevant. Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy matter for sites that need cross-origin isolation.

Content-Security-Policy is a header that tells the browser exactly which scripts, styles, images, fonts, and third-party origins are allowed to load on a page. Configured well, it drastically reduces the impact of XSS. Configured poorly, it can break your site. Start in Content-Security-Policy-Report-Only mode to measure impact before enforcing.

HSTS (Strict-Transport-Security) tells modern browsers to only reach your site over HTTPS for a period specified by max-age. Adding includeSubDomains extends that to every subdomain, and preload allows submission to a browser-shipped list. Both are hard to reverse, so only enable them after verifying every subdomain works over HTTPS.

X-Content-Type-Options: nosniff tells the browser to trust the Content-Type header you send instead of trying to guess. That prevents MIME-sniffing attacks where a browser reinterprets a file as executable content. It is a one-line, low-risk addition to almost any site.

Not automatically. A missing header often just means the site never opted into an extra protection, not that a specific bug exists. Whether it matters depends on what the site does, how it authenticates users, and what browsers rely on. This tool flags what is missing without declaring the site insecure.

Access-Control-Allow-Origin tells browsers which origins are allowed to read the response cross-origin. A wildcard (*) means any browser origin can read it, which is normal for public APIs and static assets. It only becomes risky when combined with credentials or when the endpoint returns private data.

No. This tool checks HTTP response headers only. It does not test authentication, business logic, TLS configuration, input validation, dependency vulnerabilities, or anything else that is not visible in the response headers. Use it alongside a real security review, not as a replacement.