How to Check Security Headers

HTTP security headers are your web server’s first layer of defense against common attacks, yet many sites ship with none of them configured. Running a security headers check against your site takes seconds and immediately reveals gaps that attackers can exploit.

The security header checklist

A well-configured site should include most of these headers in every response:

• Strict-Transport-Security (HSTS): Tells browsers to only connect over HTTPS for a specified duration. A value like max-age=31536000; includeSubDomains enforces HTTPS for one year across all subdomains. Once a browser sees this header, it will refuse plain HTTP connections even if a user types http:// manually.
• Content-Security-Policy (CSP): Controls which resources the browser is allowed to load. This is the most complex header to configure but also the most powerful defense against XSS. See the CSP header generator guide for details.
• X-Frame-Options: Prevents your site from being embedded in an <iframe> on another domain, which blocks clickjacking attacks. Set to DENY or SAMEORIGIN. Note that the newer frame-ancestors CSP directive supersedes this header, but X-Frame-Options provides backward compatibility.
• X-Content-Type-Options: Set to nosniff to prevent browsers from MIME-sniffing a response away from the declared Content-Type. This stops attacks where a malicious file disguised as an image is interpreted as a script.
• Referrer-Policy: Controls how much URL information is sent in the Referer header when navigating away from your site. strict-origin-when-cross-origin is a sensible default that sends the origin for cross-site requests but the full URL for same-site navigation.
• Permissions-Policy: Restricts access to browser features like camera, microphone, geolocation, and payment APIs. If your site does not use these features, explicitly disabling them prevents injected scripts from accessing them.

Tips and best practices

• Fix critical headers first. HSTS and CSP provide the highest security value. Missing X-Content-Type-Options is easy to add but lower impact.
• Test with and without www. Your bare domain and www subdomain may return different headers if they are served by different configurations. Check both.
• Set headers at the server level, not the application level. Configuring headers in Nginx or Apache ensures they apply to static files, error pages, and redirects — not just application-generated responses.
• Re-check after deployments. New middleware, updated CDN configurations, or application framework upgrades can silently drop security headers.

Troubleshooting

• HSTS not working. The browser must receive the header over a valid HTTPS connection at least once before it enforces the policy. If your SSL certificate is invalid or expired, the browser ignores the HSTS header entirely.
• Headers present in curl but not in the browser. CDNs and reverse proxies can strip or override headers. If you see the correct headers when hitting your origin server directly but not through your CDN, check your CDN’s header passthrough settings.
• Getting a low score despite having most headers. A missing CSP alone can tank your overall rating because it is weighted heavily. Even a basic CSP like default-src 'self' is a significant improvement over no policy at all.