What security headers are and which ones you need
A plain-English guide to HTTP security headers, what each one does and which ones every website should send, with how to add them without breaking the site.
Security headers are one of the cheapest ways to make a website safer. They are a few lines of configuration, they take minutes to add, and they close off a set of common attacks. Here is what they are and which ones you actually need.
What a security header is
Every time a browser requests a page, the server sends back the page plus a set of headers: instructions about how the browser should treat the response. Security headers are the subset of those instructions that tell the browser to behave more defensively: always use HTTPS, do not guess file types, do not let other sites frame this page, and so on.
They are sent by the server or the CDN, not written into the page, so adding them is a configuration change rather than a code change.
The ones that matter
Strict-Transport-Security (HSTS). Tells the browser to only ever connect over HTTPS, even if someone types http. It stops downgrade attacks where traffic is forced back onto an insecure connection. Start with a short max-age, confirm nothing breaks, then raise it.
Content-Security-Policy (CSP). The most powerful and the most fiddly. It controls where scripts, styles and other resources are allowed to load from, which shuts down most cross-site scripting. Introduce it gradually, because a strict policy can block inline scripts or third-party tools until you allow them.
X-Content-Type-Options. A one-liner, nosniff, that stops the browser guessing a file type and running something as a script that should not be. There is no reason not to set it.
X-Frame-Options or frame-ancestors. Stops other sites loading your page inside an iframe, which prevents clickjacking. Modern setups use the CSP frame-ancestors directive, but the older header still works.
Referrer-Policy. Controls how much of the referring URL is shared when a visitor clicks away. A sensible value like strict-origin-when-cross-origin protects privacy without breaking analytics.
Permissions-Policy. Lets you switch off browser features the site does not use, like the camera, microphone or geolocation, so a compromised script cannot reach for them.
Which ones you need
For almost any site: HSTS, X-Content-Type-Options, a Referrer-Policy and frame protection are quick wins with little risk. Add them first.
Content-Security-Policy is the big one. It takes the most effort because you have to allow every legitimate resource, but it is also the header that does the most. Build it up gradually, test as you go, and use report-only mode first if your platform supports it.
Add them without breaking the site
The headers above are mostly safe to add straight away. CSP is the exception, so treat it carefully: start permissive, watch for blocked resources, then tighten. After any change, re-check, because a deploy or a CDN tweak can quietly drop a header you thought was set.
You can check a page right now with the free security headers checker. It grades a URL on the headers above and shows what is missing.
Keep them in place over time
Headers regress. A new deploy, a CDN change or a platform update can drop one without anyone noticing, and a header that is not there protects nothing. On a client site, that is the kind of quiet regression you want to catch before an auditor does.
Janitor checks security headers on every site you manage on a schedule and flags any that disappear, alongside mixed content and the rest of the security category, in a branded report.