HTTP Headers
Inspect the HTTP response headers for any domain and check which security headers are present.
| Security header | Status | Value |
|---|
| Header | Value |
|---|
About the HTTP Headers checker
HTTP response headers carry important information beyond the visible content of a page, including security policies, caching rules, and server configuration details. Missing or weak security headers are a common and often overlooked vulnerability, since a site can function perfectly while still lacking protections against common attack types. This tool retrieves and explains the headers a domain is sending, flagging security headers that are present, missing, or could be strengthened.
How it works
DNSbyte sends a request to the domain and captures the full set of response headers returned, then checks specifically for security-relevant headers including Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Strict-Transport-Security among others. Each is evaluated for presence and, where applicable, whether the configured value follows commonly recommended practice rather than just technically existing.
Headers that reveal unnecessary information about server software and version, which can help an attacker narrow down known vulnerabilities, are also flagged.
Frequently asked questions
Why does a missing security header matter if my site has no obvious vulnerabilities?
Security headers are a defence in depth measure, they reduce the impact of certain attack types even if no other vulnerability currently exists. For example, a missing X-Frame-Options header means your site could be embedded in an invisible iframe on a malicious site as part of a clickjacking attack, regardless of how secure your own code is.
What does X-Content-Type-Options nosniff actually protect against?
It stops browsers from trying to guess a file's type based on its content rather than trusting the declared Content-Type header, which prevents certain attacks where a malicious file is disguised as something harmless like an image to trick the browser into executing it.
My Content-Security-Policy header is present but still gets flagged, why?
CSP can be present but configured too permissively to provide meaningful protection, for example allowing scripts from any source rather than an explicit allowlist. The check looks at whether the policy is restrictive enough to actually be useful, not just whether the header exists at all.
Should I remove headers that reveal my server software?
It is generally good practice to suppress headers like Server or X-Powered-By that reveal specific software and version numbers, since this information makes it easier for an attacker to look up known vulnerabilities for that exact version, even though hiding it alone does not make your site secure.
Why do some of these headers not apply to API endpoints the same way?
Headers like Content-Security-Policy are primarily relevant to pages that render HTML and execute scripts in a browser, while a pure API endpoint returning JSON has a different threat model and different recommended headers, so a lower score on browser-focused headers is not necessarily meaningful for an API-only path.