HTTP Headers Checker guide

What security headers do

Every HTTP response carries headers that browsers read before rendering the page. A handful of them switch on protections that the browser cannot apply by default without breaking older sites: HTTPS-only access, restrictions on script sources, protection against being framed by another site. Sending them costs almost nothing and closes whole classes of attacks.

Headers are per response. A header set in one server block or application route does not automatically apply to others, and proxies or CDNs can add, change or remove them. That is why checking the real response from outside is more reliable than reading configuration files.

How to use the HTTP Headers Checker

1. Open the HTTP Headers Checker and enter a domain, for example example.com.
2. XGM requests https://example.com, follows redirects and reads the headers of the final page.
3. Review the verdict and the finding per header, the CSP analysis (unsafe sources, missing directives, reporting) and the cache headers. Missing or weak headers include a snippet for nginx, Apache, Caddy and Cloudflare you can copy.
4. Open "All response headers" to see the raw list, including caching and server headers.
5. After changing your configuration, run the check again; the permalink keeps the domain in the URL. The Full report tab adds a scored header report with recommendations.

Because headers come from the final page, a redirect from example.com to www.example.com means you see the headers of www. Check the bare domain's redirect responses with the Redirect Checker, especially for HSTS, which should also be sent on redirects.

The headers and what the checker expects

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Version leaks and cookie flags

Headers such as Server: nginx/1.18.0 or X-Powered-By: PHP/7.4.3 tell anyone which software versions you run. That does not create a vulnerability, but it saves attackers time when a version has known problems. The checker reports version numbers in Server, X-Powered-By and ASP.NET version headers as informational findings.

# nginx
server_tokens off;

# PHP (php.ini)
expose_php = Off

Cookies set by the page are checked for three flags. Secure keeps the cookie off plain HTTP, HttpOnly hides it from JavaScript, which matters for session cookies, and SameSite limits when the browser sends it with cross-site requests. A session cookie without them is easier to steal or misuse.

Set-Cookie: session=4f9c2b…; Path=/; Secure; HttpOnly; SameSite=Lax

Common mistakes

The X-XSS-Protection header is sometimes still recommended by old checklists. Modern browsers removed the feature it controlled, and the header is no longer useful; a Content Security Policy replaces it.

Setting headers on other servers and platforms

The nginx snippets in the findings translate directly to other web servers. Set the headers once, at the layer that serves every response, and prefer the web server or CDN over application code so static files and error pages get them too.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

example.com {
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }
}

CDNs and hosting platforms usually offer a rules or headers section in their dashboard, or a configuration file in the repository, for adding response headers. After changing them, purge cached responses if the platform caches headers along with content, then check again from outside.

Keep a short record of which layer owns each header. When a site moves to a new platform, security headers are among the settings most often lost, because nothing breaks visibly when they disappear. Running the checker after every migration catches that in seconds.

Other headers worth a look

The raw header list also shows caching and performance settings. Cache-Control decides how long browsers and CDNs keep a response, and pages with personal data should use private or no-store. Compression shows up as Content-Encoding: gzip or br, and Vary explains which request headers change the response.

Cross-origin isolation headers (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy) matter for applications that need powerful browser features or want strict isolation from other sites. They are not required for most websites, so the checker lists them without grading them.

FAQ

Sources

• MDN: HTTP headers reference
• RFC 6797: HTTP Strict Transport Security
• W3C: Content Security Policy Level 3
• RFC 6265: HTTP State Management Mechanism (cookies)
• OWASP HTTP Security Response Headers Cheat Sheet