HTTP Security Headers Explained: CSP, HSTS and More
HTTP security headers are response headers that ask supporting browsers to apply policies such as restricting content sources, preferring HTTPS, limiting framing, or controlling browser capabilities.
How it works
A server, application, CDN, or reverse proxy includes headers in an HTTP response, and a browser interprets the policies it supports for that response or host. Different headers address different browser-side risks. They are one security layer: presence does not prove a site is secure, and absence alone does not prove a site is compromised or unsafe.
Content Security Policy (CSP)
Content-Security-Policy restricts where a browser may load resources such as scripts, styles, images, frames, fonts, and network connections. A directive such as default-src 'self' provides a default that allows covered resource types from the same origin, although a real policy normally needs to reflect the application's actual resources and behavior.
A carefully designed CSP can reduce the impact of some content-injection and cross-site scripting scenarios by blocking unauthorized resource and script execution paths. It does not guarantee that an application has no injection flaw, and permissive sources or keywords can substantially weaken the intended restriction.
A report-only policy can help an operator observe potential violations without enforcing them. The presence of either an enforced or report-only header is therefore not enough to judge quality: directives, affected pages, browser support, and application requirements all need review.
HSTS and HTTPS enforcement
Strict-Transport-Security, commonly called HSTS, tells supporting browsers to use HTTPS for future requests to a host for the published max-age period. The browser must receive an active policy over a valid HTTPS connection before an ordinary HSTS header takes effect.
HSTS does not add encryption to an HTTP-only site or repair an invalid TLS deployment. A max-age of zero disables the stored policy, while includeSubDomains extends it to subdomains and therefore requires careful operational planning. Preloading is a separate browser-maintained mechanism and should not be treated as a casual checkbox.
The header belongs on the final HTTPS response that should establish the policy. A redirect from HTTP to HTTPS is useful, but an HSTS field observed only on the HTTP response is not protective. Certificate coverage, renewal, and TLS configuration remain separate responsibilities.
Other common browser security headers
X-Content-Type-Options: nosniff asks browsers not to reinterpret certain resources as a different MIME type. Referrer-Policy controls how much referrer information a browser includes in outgoing requests, and Permissions-Policy can limit access to selected browser features for the page and embedded content.
Framing can be controlled with the CSP frame-ancestors directive or, for established compatibility, X-Frame-Options values such as DENY or SAMEORIGIN. CSP frame-ancestors is the more flexible modern control. The older ALLOW-FROM form is not a reliable modern substitute.
Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy support cross-origin isolation and resource controls in applications that need them. They are context-dependent rather than mandatory for every site. Historical headers such as X-XSS-Protection and Expect-CT should not be counted as modern protection merely because an older scanner expected them.
How to interpret security-header results
A present header can still contain a weak, incomplete, conflicting, or application-breaking policy. A missing header may be an important hardening opportunity, irrelevant to a particular response, or addressed by another control. Evaluate the value and application context rather than treating presence as a pass and absence as a vulnerability.
Headers can differ by URL path, redirect hop, CDN edge, authentication state, cookies, request method, and deployment layer. A CDN or reverse proxy may add or replace a value. Inspect the final response that serves the relevant content, while checking earlier redirects separately when their behavior matters.
The Security Headers Checker follows a bounded public redirect chain, evaluates selected headers on the final response, and produces a limited coverage assessment. It does not execute the application, log in, inspect every route, exhaustively validate policy directives, or scan for vulnerabilities. Its result is configuration evidence, not a site-security grade.
Practical guidance
- Inspect the actual header values on the final public response, not only whether each name exists.
- Test policies against the application's required resources and browser behavior before enforcing them broadly.
- Review application, authentication, dependency, server, cookie, and TLS security separately from response-header coverage.
Common question
Does having all the recommended security headers make a website secure? No. Headers address particular browser-side risks, while application flaws, authentication, authorization, dependencies, server configuration, TLS, and other controls remain separate.