HTTP security headers: HSTS, CSP and the rest, the protection almost nobody switches on

Your site can have an HTTPS padlock and still leave easy doors open: someone embedding it in another page to trick your visitors, an uploaded file running as if it were code, or a foreign script slipping in. Security headers close many of those doors.

They're instructions your server sends to the browser along with each page, roughly: with this site, behave this way. They don't replace keeping your system updated or using decent passwords, but they're cheap to add and cut off common attack routes.

HSTS: always force HTTPS

Strict-Transport-Security (HSTS) tells the browser that, for a set time, it should only connect to your domain over HTTPS. Even if someone types http:// or follows an old link, the browser itself upgrades it to https:// before sending anything. It protects against attacks that try to downgrade the connection to an unencrypted one. An example: Strict-Transport-Security: max-age=31536000; includeSubDomains.

One thing to watch: if you enable it with a long duration and some subdomain doesn't have HTTPS properly set up, it will be unreachable until the setting expires. Start with a low value (for example max-age=300, five minutes) and raise it gradually.

Content-Security-Policy: deciding where your site may load things from

Content-Security-Policy (CSP) is a list of allowed sources for scripts, styles, images, fonts or frames. If an attacker manages to inject a script into your page (known as XSS), the browser blocks it because it doesn't come from an authorised source. A very simple starting point is default-src 'self', which only allows resources from your own domain.

It's the most powerful header and also the easiest to break: your analytics, chat, maps, external fonts or any script written inside the HTML itself must be allowed explicitly. That's why it isn't switched on blindly.

Three simple headers: nosniff, framing and referrer

X-Content-Type-Options: nosniff stops the browser from guessing a file's type and forces it to respect the one the server declares. It prevents, for example, an uploaded file from running as a script.

X-Frame-Options (with DENY or SAMEORIGIN) and the CSP frame-ancestors directive stop other sites from displaying yours inside a frame, a technique used to trick visitors into clicking where they didn't intend to (clickjacking). frame-ancestors is the modern way and takes precedence over the old one, so many people set both.

Referrer-Policy, for example with strict-origin-when-cross-origin, controls how much information about the originating page is sent when someone clicks a link to another site. It avoids leaking internal addresses that contain sensitive data.

Permissions-Policy: switch off what you don't use

Browsers offer features like camera, microphone or geolocation. Permissions-Policy lets you disable them for your page and for everything you embed in it. For instance, Permissions-Policy: camera=(), microphone=(), geolocation=() turns them all off.

It's especially useful if you embed third-party content, because that content won't be able to ask for permissions your site doesn't need. If you use a map with location or video calls, don't disable that specific feature.

How to add them without breaking your site, and how to check them

The key is test mode. CSP has a version that blocks nothing, Content-Security-Policy-Report-Only: the browser just reports in the developer tools console what it would have blocked. Leave it running for a few weeks, fix whatever is legitimate, and only then enforce it.

A sensible order: first nosniff, Referrer-Policy and Permissions-Policy, which rarely cause trouble; then the framing ones; then HSTS gradually; and CSP last. To check, run curl -I https://yourdomain.com or open the browser's Network tab and look at the Response Headers. There are also free online analysers that grade your headers. After each change, test forms, payments, maps and embedded videos.

Frequently asked questions