HTTP Security Headers: What Each Header Actually Does
Reviewed September 3, 2026 · Maintained by William
Security headers are small HTTP response fields with very different jobs. Adding them as a checklist without understanding those jobs can break functionality or leave important gaps.
Strict-Transport-Security (HSTS)
HSTS tells supporting browsers to use HTTPS for a host for a period of time. It should only be sent over HTTPS. includeSubDomains and preload are stronger commitments; do not enable them until every affected hostname is ready.
Content-Security-Policy (CSP)
CSP restricts which resources can load or execute and can also block framing and risky base URLs. It is powerful but application-specific. Test with report-only before enforcing a new policy.
X-Content-Type-Options: nosniff
This asks browsers not to reinterpret certain resource MIME types. It is a low-cost hardening header, but it also means your server should send correct Content-Type values.
Referrer-Policy
This controls how much referrer information the browser sends when navigating or fetching subresources. strict-origin-when-cross-origin is a common modern balance, but privacy and analytics requirements vary.
Permissions-Policy
This can disable or constrain browser features such as camera, microphone, geolocation and payment APIs. Start by denying features the site never needs.
X-Frame-Options
This older header can prevent framing with DENY or SAMEORIGIN. Modern CSP frame-ancestors is more expressive; some deployments send both for compatibility.
Headers do not replace application security
They cannot fix SQL injection, broken authentication, unsafe authorization or vulnerable dependencies. They reduce particular browser-side risks and should complement secure application design.
Use the HTTP Header Parser to inspect copied response headers and the CSP Header Generator to draft a policy, then validate against authoritative documentation.
References
Security headers solve different problems
There is no single “security headers” switch. Each header influences a different browser behavior, and some older headers have been superseded by newer mechanisms. Build a policy from the application’s needs rather than chasing a score without understanding side effects.
Strict-Transport-Security (HSTS)
HSTS tells supporting browsers to use HTTPS for the host for a specified period after receiving the header over HTTPS.
Strict-Transport-Security: max-age=31536000; includeSubDomainsDo not add includeSubDomains or preload casually. Every covered subdomain needs reliable HTTPS before you make that commitment.
X-Content-Type-Options
X-Content-Type-Options: nosniffThis reduces MIME-sniffing behavior and makes correct Content-Type headers more important. Fix incorrect MIME types rather than removing the protection to make a resource load.
Referrer-Policy
Referrer Policy controls how much source URL information is sent in the Referer header. A value such as strict-origin-when-cross-origin is a common balance, but applications handling sensitive path/query information should review their navigation flows carefully.
Permissions-Policy
This can restrict powerful browser features such as camera, microphone or geolocation. The right directive depends on which features the site actually uses and whether embedded frames need them.
Content-Security-Policy
CSP controls allowed resource sources and can mitigate classes of injection attacks. It needs application-specific testing; a copied policy can break third-party integrations or remain too broad to add much protection.
Headers must be present on the responses that matter
A configuration that adds headers only to 200 responses can leave redirects or error pages behaving differently. When your web server supports an “always” form, understand how it interacts with upstream application headers and avoid accidentally duplicating values.
Verification workflow
- Use browser developer tools or
curl -Ito inspect the actual HTTPS response. - Check redirects and representative error responses, not just the homepage.
- Confirm there are not conflicting duplicate headers from CDN, proxy and application layers.
- Test features affected by CSP, Permissions Policy and framing rules.
- Document why each policy exists so future maintainers do not remove it blindly.
A header scanner is not the final authority
Automated scanners are useful for finding missing headers, but they cannot know whether a strict-looking value matches your application. For example, a CSP can receive a high-level “present” result while still allowing broad sources, and HSTS can cause operational trouble if enabled for subdomains that are not ready.
Use the HTTP Header Parser or related header utilities as a starting point, then verify against current MDN/OWASP and server documentation and test the deployed responses.