Security headers explained: the six lines that protect your visitors

The short answer

Every time a browser loads a page from your site, your server sends a few lines of text along with it. Some of those lines are instructions about security: only use encrypted connections, do not let other websites embed this page, only run scripts that come from here. Browsers follow them. Without them, browsers fall back to permissive defaults that were designed for a friendlier web.

Six headers cover most of the ground. A security scan checks all six, and a site that has never been configured is missing at least four.

The six, in one table

Header	What it tells the browser	What can happen without it
Strict-Transport-Security (HSTS)	Only ever use HTTPS for this domain	The first request can be intercepted on hostile networks
X-Content-Type-Options	Do not guess file types, trust what I say	A disguised file can be executed as a script
X-Frame-Options or CSP frame-ancestors	Do not let other sites put this page in a frame	Clickjacking: your page overlaid with invisible buttons on a malicious site
Referrer-Policy	How much of the current address to share when a visitor clicks away	Private URLs and query details leak to third parties
Permissions-Policy	Which browser features this page may use, such as camera, microphone, location	Embedded scripts can request powerful features in your name
Content-Security-Policy (CSP)	Exactly where scripts, styles, images and frames may come from	An injected script runs with full access to the page

The quick five

Five of the six are safe defaults. They rarely break anything and can be set in an afternoon.

The one that takes longer: Content Security Policy

CSP is the most powerful header and the only one that needs real work. It lists where scripts, styles, images, fonts and frames may be loaded from. Anything not on the list is blocked. That is exactly why it stops injected scripts, and exactly why it breaks things when the list is incomplete. One value decides how much of that protection you keep: where script-src contains 'unsafe-inline', a script written straight into the page still runs, and the policy only covers what is loaded from elsewhere. The article on Content Security Policy sets out the two ways around that.

Where the headers live

On modern static hosting, headers are a small configuration file in the project, deployed with the site and versioned with the code. On traditional hosting they are set in the web server configuration. On a content system with plugins, they are sometimes set by a plugin, which works until the plugin is updated or removed.

Whichever it is: check the headers after every migration, every hosting change and every new tag. They are the first thing to silently disappear when something moves.

What this means for you

Ask for the response headers of your homepage, or run a scan. If four or more of the six are missing, the quick five are an afternoon of work for whoever runs your hosting, and CSP is a week of careful testing. Both are cheaper than the incident they prevent.