networkutils.org

Home / Blog / A Field Guide to HTTP Security Headers

Security

A Field Guide to HTTP Security Headers

Security headers are cheap, effective, and frequently missing. A practical tour of HSTS, CSP, referrer, and frame policies — what each does and how to audit them.

HTTP security headers are among the highest-value, lowest-cost defences a site can deploy. They require no application changes, no infrastructure, and no ongoing maintenance beyond an occasional review — yet a surprising number of sites ship without them. A security headers audit takes seconds and tells you exactly what is missing.

Strict-Transport-Security (HSTS)

HSTS tells browsers to always connect to your site over HTTPS, never HTTP, for a period you specify. Once a browser has seen the header, it will refuse plain HTTP connections to your domain and will not click through certificate warnings. This defeats SSL-stripping attacks that downgrade a user to HTTP.

Set a max-age of at least six months, include the includeSubDomains directive only if every subdomain is also HTTPS, and consider the preload directive once you are confident — submitting to the HSTS preload list means browsers will enforce HTTPS even on the very first visit.

Content-Security-Policy (CSP)

CSP is the most powerful and the most finicky header. It restricts where the browser may load resources from — scripts, styles, images, frames, fonts, connections — and is the primary defence against cross-site scripting. A strict policy like default-src 'self' blocks inline scripts and external loads entirely.

The difficulty is that a strict CSP breaks sites that rely on inline scripts or third-party widgets. Roll out in Report-Only mode first: the browser reports violations without enforcing them, so you can see what would break before you flip to enforcement. Tighten the policy until the reports stop, then enforce.

Referrer and frame policies

Referrer-Policy controls how much of the URL the browser sends in the Referer header when navigating away. strict-origin-when-cross-origin is a sensible default: full URL for same-origin, origin only for cross-origin, and nothing when going from HTTPS to HTTP.

X-Frame-Options (or the frame-ancestors directive in CSP) prevents your site from being embedded in an iframe on another domain, defeating clickjacking. Use frame-ancestors in CSP if you already have one; it supersedes the older header and is more flexible.

Auditing in seconds

Each header is independent, so you can deploy them one at a time and verify each. Run a security headers audit against your site and it will report which headers are present, which are missing, and whether the present ones are configured correctly. Fix the gaps, re-audit, and you have materially improved your site’s posture in minutes.

None of these headers replaces application-level security, but together they close a class of browser-side attacks that would otherwise be open. There is rarely a good reason to ship without them.