Security headers are HTTP response instructions that help browsers handle a website’s content and connections more safely. I recommend that website owners, marketers, developers, and agencies treat them as part of routine site maintenance, not a one-time checklist. The practical goal is to reduce specific browser-side risks while avoiding policies that break legitimate features.
Key takeaways
- Headers can limit scripts, require HTTPS, control framing, and reduce unnecessary referrer sharing.
- There is no universal policy that fits every website. Configure rules around the site’s actual resources and features.
- Test changes on real responses, including redirects, subdomains, and key application routes.
- Use ongoing monitoring to catch configuration drift after deployments or infrastructure changes.
What do browser security headers control?
Security headers are fields in an HTTP response that tell a browser what behavior to allow or restrict. For example, a response can limit which sources may load scripts or tell a browser to use HTTPS for future visits.
They reduce exposure to certain attacks, but they do not repair insecure application code or replace authentication, access controls, and secure transport. I use the OWASP HTTP headers guidance as a technical reference, then assess each rule against the site’s real needs.
A header check is only useful when it reflects the response visitors receive. A CDN, reverse proxy, application server, or hosting platform may each set or override headers, so inspect the public site rather than relying only on a local configuration file.
Which response headers should I prioritize?
I prioritize headers by the risk they address and the chance of disrupting real site behavior. This table gives a starting point, not a universal policy.
| Header | Primary purpose | Important caution |
|---|---|---|
Content-Security-Policy | Restricts the sources browsers can load or execute. | Test carefully; strict rules can block scripts and other resources the site needs. |
Strict-Transport-Security | Instructs browsers to use HTTPS for future connections. | Enable only after HTTPS works reliably across the covered hostnames. |
X-Content-Type-Options: nosniff | Stops browsers from guessing a different content type. | Serve accurate Content-Type values for files and responses. |
frame-ancestors in CSP | Controls which sites may embed a page in a frame. | Allow trusted embedding partners when the product requires them. |
Referrer-Policy | Limits referrer details shared with other sites. | Choose a setting that fits analytics and navigation needs. |
Permissions-Policy | Restricts access to browser features such as camera or location. | Allow only features the site actually uses. |
For clickjacking protection, I prefer the CSP frame-ancestors directive where supported, while X-Frame-Options can remain useful for compatibility. The right choice depends on whether the site should ever appear inside another page.
How can I roll out CSP without breaking the site?
Build Content-Security-Policy from observed site behavior, then tighten it in stages. Start by listing the origins that provide scripts, styles, images, fonts, APIs, and other resources. Review third-party tags and embedded tools too, since they can introduce dependencies that are easy to miss.
I recommend deploying a report-only policy first. It lets a team identify violations without blocking resources, so developers can distinguish expected integrations from unexpected sources. The MDN CSP reference explains the available directives and report-only behavior. After reviewing reports and testing key user journeys, move to enforcement and keep checking for regressions. A Content Security Policy audit can help surface the policy currently served to visitors.
Enable HSTS only after HTTPS is stable
Strict-Transport-Security tells browsers that they should use HTTPS on later visits. I would first confirm that the certificate is valid, every required page loads over HTTPS, and HTTP requests redirect correctly. Then introduce a suitable max-age and increase it as confidence grows.
Be cautious with includeSubDomains and preload eligibility. These choices can affect subdomains that teams may not have tested, including older services or third-party systems. Check the intended scope with an HSTS preload configuration check before applying a policy broadly.
HTTPS and the www hostname solve different problems. HTTPS encrypts the connection; www is just one possible hostname. Secure the root and www versions, select a canonical URL, and redirect consistently.
Set framing and privacy controls deliberately
Frame restrictions should match how the website is used. A banking or account page may not need third-party embedding, while a product widget might. Configure frame-ancestors or X-Frame-Options accordingly, then test login, checkout, and embedded workflows. A dedicated frame protection check can reveal the header visitors receive.
Referrer and permissions controls need similar care. A policy such as strict-origin-when-cross-origin can reduce path and query details shared with other origins while preserving the origin. Restrict camera, microphone, and location access if the site does not need them. I use a Referrer-Policy check and a Permissions-Policy check to review these controls.
Test public responses and monitor for drift
Test the response visitors actually receive, including the final destination after redirects. A HEAD request may not always match a normal page request, so verify key routes in a browser or with a request that retrieves the page. Check the homepage, login or checkout, subdomains, APIs, and pages with distinct integrations.
I also check that headers are not duplicated or contradictory across the application, server, and CDN. After changes, test important user journeys, then repeat checks after deployments or infrastructure updates. 37 Audits helps teams monitor website configuration continuously, so missing or changed controls can be found before they become a larger security or reliability issue.
Frequently asked questions
What are security headers?
Security headers are HTTP response fields that tell a browser how to handle a site’s content and connections. They can restrict where scripts load from, require HTTPS, limit framing, or control referrer details. They reduce specific browser-side risks, but they do not replace secure code, access controls, or TLS configuration.
Which is safer, www or HTTPS?
HTTPS provides transport encryption; www is simply a subdomain. A site can use HTTPS with or without www, and neither hostname is inherently safer. I recommend securing both versions, choosing one as the canonical address, and redirecting the other to it over HTTPS.
Do security headers prevent all website attacks?
No. Response headers can reduce risks such as some forms of cross-site scripting, clickjacking, and insecure connections, but they cannot prevent every attack. They work best alongside secure application code, patching, authentication, access controls, and careful handling of user input.
Which security headers should I configure first?
I would first confirm that HTTPS works across the site, then add a carefully tested HSTS policy, X-Content-Type-Options, a suitable frame restriction, and a Referrer-Policy. Build Content-Security-Policy around the site’s actual resources, starting in report-only mode to find breakage before enforcing it.
How can I check my website’s security headers?
Check the live HTTP response for the public URL, then test important pages, redirects, subdomains, and API routes separately. Browser developer tools and command-line requests can help. I also recommend continuous monitoring, since a CDN, server change, or deployment can alter headers after an initial check.
