The instructions your website isn't giving the browser

What a response header actually is

When someone visits your site, your server sends the page — and alongside it, a short set of instructions to the browser. Most of those instructions are mundane: here is the file type, here is how long to cache it. A handful of them are safety instructions: don't let other sites frame this page, don't guess at file types, only connect over an encrypted connection. Sending nothing is the default. Most sites send nothing.

The ones that matter, by what goes wrong without them

Content-Security-Policy — someone can get code onto your page and the browser will run it. If an attacker manages to inject a script (through a comment box, a review form, a compromised plugin), CSP is what tells the browser "scripts only load from these approved places" and refuses the rest. Without it there is nothing standing between injected code and your visitors' data — including what they type into a checkout form. Roughly 22% of sites send one.

Strict-Transport-Security — a visitor's first connection can be intercepted. If someone on a coffee-shop network types your domain without "https", that first request goes out unencrypted and can be captured and redirected. This header tells the browser to only ever connect securely to your site, and not to let visitors click through certificate warnings. About 36% of sites send one.

Frame protection — another site can wrap yours inside an invisible layer. In a clickjacking attack the visitor believes they are clicking a button on the attacker's page, but they are actually clicking a real button on yours, while logged in. In 2009 a Twitter worm did this at scale with a "Don't Click" button; Twitter deployed a JavaScript defence, and the attack was modified to defeat it within hours. That is the argument for handling this at the header level rather than in page code. Note the current guidance: the older X-Frame-Options header has been formally obsoleted in favour of the frame-ancestors directive inside Content-Security-Policy, and where both are present, frame-ancestors wins. Setting both is harmless and still expected by many compliance checklists, but frame-ancestors is what is actually protecting a modern visitor.

X-Content-Type-Options — the browser second-guesses what a file is. Without it, a browser may inspect a file you served as plain text or as an image, decide it looks like a web page, and run it as one. This matters most if your site accepts uploads — customer photos, CVs, documents. The fix is a single word: nosniff.

Two we will be straight with you about

Referrer-Policy is worth setting, but the usual scare story overstates it. Modern browsers already default to sending only your domain name — not the full page address — to other sites, and nothing at all when going from an encrypted page to an unencrypted one. Setting it explicitly protects you against a misconfiguration elsewhere and documents your intent. It is good hygiene rather than an open door.

Permissions-Policy switches off browser capabilities your site doesn't need — camera, microphone, location — including for content you embed from third parties. It is genuinely useful hardening. But browser support is still incomplete, and the browser prompts the visitor for these permissions regardless, so nobody is silently exposed without it. Roughly 4% of sites send one, and we do not think that number is a scandal.

An honest note about evidence

We looked for a documented real-world incident caused by a missing X-Content-Type-Options header and could not find one — everything available is demonstrations and bug-bounty write-ups rather than a case where real people were harmed. We are telling you that rather than reaching for a weak example. The clickjacking and unencrypted-session cases above are real and documented; the file-type one is a sound precaution without a headline attached to it.

How to fix it

In most setups this is a settings change, not a development project. If you sit behind Cloudflare, it is a Transform Rule. On WordPress, a security plugin or a few lines in your server configuration. On a static host, usually a headers configuration file. Start with Strict-Transport-Security, nosniff, and frame-ancestors — those three are near-zero-risk. Content-Security-Policy is the one to introduce carefully, because a strict policy can block your own scripts; deploy it in report-only mode first, watch what it would have blocked, then enforce.

Sources

• MDN Web Docs — Content-Security-Policy
• MDN Web Docs — Strict-Transport-Security
• MDN Web Docs — X-Content-Type-Options
• MDN Web Docs — Referrer-Policy
• OWASP — HTTP Headers Cheat Sheet
• OWASP — Clickjacking Defense Cheat Sheet (on X-Frame-Options obsolescence)
• HTTP Archive — Web Almanac 2025, Security chapter (July 2025 crawl, 16.2m sites)
• The Register — Twitter clickjacking worm (February 2009)
• Office of the Privacy Commissioner of Canada — Firesheep (November 2010)