HTTP Security Headers — A Second Line of Defense That Tells the Browser How to Defend Itself

Browsers are built to maintain compatibility with old HTML and old protocols. For example, by default clicking an HTTP link establishes an unencrypted connection, JavaScript fetched via <script src="..."> runs, and being embedded in someone else's <iframe> is allowed. These are correct as Web features, but to an attacker they are ready-to-use attack surface.

Security headers are the mechanism for the site operator to tell the browser "turn off the old behavior for our site". Instead of the server defending, the browser defends. So they only work for Web apps where the audience is "browser users" — curl and custom scripts ignore them. Conversely, they have massive effect specifically against attacks that come through browsers (XSS / clickjacking / MIME sniffing, etc.).

Organized by attack:

These are mutually orthogonal — no single one is sufficient; only the full set forms a complete layered defense.

HSTS (HTTP Strict Transport Security, RFC 6797) is a header that tells the browser to remember "never connect to this site over HTTP". Once issued, even if the user types http://example.com/login or clicks an http:// link in the URL bar, the browser rewrites it to https:// before contacting the server.

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

preload is opt-in — register at hstspreload.org and you get hard-coded into Chrome / Firefox / Safari, so HSTS applies to brand-new users who have never visited the site. The flip side: "once registered, removal is very heavy (list propagation takes months)", so register only after you're confident about running HTTPS-only in production.

There was also HPKP (Public-Key-Pins), a "certificate public-key pinning" header introduced around 2012, but misconfigurations frequently bricked sites permanently, and it was removed in Chrome 72 (2019). The current standard is "Certificate Transparency (CT) logs + CAA records"; header-based pinning is no longer recommended.

Content-Security-Policy (CSP) is the most powerful and the most difficult among security headers. It blocks XSS and inline-script-injection attacks via a whitelist approach: "only what is permitted runs". Even if the attacker injects <script>, the browser refuses to run anything CSP didn't allow.

Common directives:

A reasonable modern baseline:

The key is to go nonce-based. Using 'unsafe-inline' collapses CSP's defensive value — inline <script>...</script> becomes wide-open, so the moment XSS lands, CSP is effectively gone. Instead, generate a random nonce per request on the server and tag only your own script tags as <script nonce="abc123">. The attacker doesn't know the correct nonce, so they can't inject one.

For phased introduction, use Content-Security-Policy-Report-Only. Same syntax, but it reports violations without blocking. Ship it to production, gather violations like an access log, understand what breaks when you remove 'unsafe-inline', then switch to the enforcing header. Always start new deployments with report-only.

Trusted Types (require-trusted-types-for 'script') is a CSP super-feature that forbids dangerous assignments like element.innerHTML = userInput at the type level. Chromium-only for now, but as the ultimate defense against DOM-Based XSS, it's seeing adoption at large sites (Gmail / Google Search).

Clickjacking is an attack where the attacker overlays the victim site as a transparent <iframe> on top of the attacker's site, "hijacking" the user's click onto a different button. The victim thinks they clicked "Like", but behind the scenes they pressed Logout or Transfer.

Two header families stop embedding.

X-Frame-Options: DENY              # no iframe from anywhere
X-Frame-Options: SAMEORIGIN        # iframe allowed only from same origin

Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: frame-ancestors 'self' https://partner.example.com

X-Frame-Options is the older header and only takes DENY / SAMEORIGIN. CSP's frame-ancestors is its superset, accepting an allowlist of multiple origins. Setting both is fine; modern browsers ignore X-Frame-Options when frame-ancestors is present. For old-browser compatibility, having both is safer.

A third value ALLOW-FROM existed but neither Chromium nor Firefox implemented it, so it's effectively dead. "Allow iframe from a specific origin" must be done via frame-ancestors.

From here the headers are unglamorous but essential. They shave off small entry points; their presence is unflashy but there's no reason to skip them.

X-Content-Type-Options: nosniff #

By historical convention, browsers peek into binary content and guess its MIME type when the server-declared Content-Type "looks obviously wrong" (MIME sniffing). For example, a file declared image/jpeg whose contents start as JavaScript may be executed as JS depending on context. This is gold for attackers — upload JS as an "image" to an image-upload feature, then load it with <script src> is the standard pattern.

X-Content-Type-Options: nosniff

With this header, the browser completely disables sniffing and trusts the Content-Type at face value. There is no reason not to set it.

Referrer-Policy #

When clicking <a href> to navigate, the destination receives a Referer header indicating which URL you came from. To prevent URL tokens or internal tool paths from leaking, control the leak amount with this header.

Referrer-Policy: strict-origin-when-cross-origin

Modern browsers default to strict-origin-when-cross-origin when this header is unspecified, so even without it you're fairly safe, but being explicit is more robust against future behavior changes. For services that put session tokens or one-time-link tokens in URLs, lean toward no-referrer.

A header that allows Web APIs holding powerful privileges — camera, microphone, geolocation, payment, sensors — to only your own origin or specific partners. The predecessor was Feature-Policy, renamed in 2020 with cleaned-up syntax.

Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=(self "https://pay.example.com")

The idea is to default to a conservative setting: "don't let anyone use powerful APIs your site never intends to". Even if a third-party ad / analytics tag calls navigator.mediaDevices.getUserMedia(), the browser immediately rejects it if Permissions-Policy says camera=().

After the 2018 Spectre / Meltdown vulnerabilities, browsers were rewritten on the assumption that "other origins' memory inside the same process cannot be trusted". High-precision timers and shared memory like SharedArrayBuffer became usable only when the browser could isolate the origin into a separate process (cross-origin isolated). The triumvirate that declares this is COOP / COEP / CORP.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

Practically, even sites that don't use SharedArrayBuffer still get value from COOP: same-origin alone — it blocks cross-origin control via window.opener ("tabnabbing"), which matters for sites that use target="_blank" heavily. COEP requires fixing all your require-corp compatibility for any externally loaded CDN, which has substantial introduction cost. If you need OAuth popups, set COOP to same-origin-allow-popups as a compromise that allows popup communication.

Headers you think you set but that aren't actually effective produce the worst-case outcome under attack: "the wall you thought was there is missing". After deployment, verify from outside.

Read raw headers with curl #

Score with external scanners #

securityheaders.com (run by Scott Helme) is a free lightweight checker that grades A+ through F. Mozilla Observatory (observatory.mozilla.org) goes deeper, scoring overall including TLS settings and Cookie attributes. Aim for A or higher on both.

nginx implementation example #

Forgetting the trailing always means headers are not added on error pages (4xx / 5xx). Most attacker-triggered responses are errors, so always is mandatory.

Laravel implementation example #

Attach via middleware. Generate a nonce per request and embed it in CSP.

A realistic deployment order #