HTTP Security Headers Explained: HSTS, CSP, X-Frame-Options, and the Rest

HTTP security headers are the browser-enforced defence layer running between the network and your application code. Nine headers form the modern stack. Each closes a specific class of vulnerability — XSS, clickjacking, downgrade, MIME confusion, information leakage, cross-origin attacks.

This guide covers what each header does, safe defaults, deployment order, and the common ways they get misconfigured.

The Nine Headers

Deployment Order

Deploy in this order — easiest and lowest risk first:

1. X-Content-Type-Options: nosniff — no configuration, no side effects, ship today
2. Strict-Transport-Security: max-age=31536000; includeSubDomains — verify HTTPS everywhere first
3. Referrer-Policy: strict-origin-when-cross-origin — modern default, minor observability changes
4. X-Frame-Options: DENY — unless you actually get embedded in iframes
5. Permissions-Policy — deny every feature you don’t use
6. Content-Security-Policy — hardest to get right; deploy in Report-Only mode first
7. COOP + COEP — only if you need SharedArrayBuffer

The Minimum Viable Stack

If you ship nothing else, ship these five:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Five lines. Zero configuration. Blocks the majority of easy-to-exploit browser-side vulnerabilities.

The CSP Question

Content-Security-Policy is the highest-leverage header — and the one most likely to break your site on first deployment. Two-phase rollout:

Phase 1: Report-Only

Content-Security-Policy-Report-Only:
    default-src 'self';
    script-src 'self' https://cdn.example.com;
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https:;
    frame-ancestors 'none';
    report-uri /csp-report;

Run this for a week. Every violation reports to /csp-report. Review reports. Add legitimate sources. Remove or self-host the rest.

Phase 2: Enforce

Change the header to Content-Security-Policy: (drop -Report-Only). Test in staging. Monitor for a day. Ship to production.

HSTS Preload

If you’re serving HTTPS reliably on every subdomain, add preload to HSTS and submit to hstspreload.org:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Preloaded domains ship HSTS-enabled in Chrome, Firefox, Safari, and Edge — no first visit needed. Once you’re on the list, you’re committed for a long time; removing is slow.

Cookies Are Part of This

Two attributes go on every cookie:

Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax

• Secure — only send over HTTPS
• HttpOnly — hide from JavaScript
• SameSite=Lax — modern CSRF defence (Strict for high-security)

See the Cookie SameSite glossary entry for the trade-offs.

Common Mistakes

• 'unsafe-inline' in script-src — kills the majority of CSP’s XSS protection. If you’re stuck with inline scripts, use nonces ('nonce-abc123') instead.
• X-Frame-Options: SAMEORIGIN with cross-origin domains — breaks legitimate embeds silently.
• HSTS max-age=0 to disable — users who already cached the policy keep it until it expires. HSTS is a one-way street.
• CSP without report-uri / report-to — you’ll never know what’s blocked.
• Setting security headers only on some routes — attackers hit the routes without them.

Testing

Run the security headers audit to see:

• Which headers are set on your domain
• Which values are safe / recommended / dangerous
• A prioritized fix list

The tool covers every header in this guide plus modern additions (COOP, COEP, Reporting-Endpoints).

Related

Check the HSTS glossary entry, the CSP entry, and the X-Frame-Options entry for the three most-load-bearing headers.