The idea
Every time someone loads a page, your server sends the page and a short set of notes alongside it. Those notes are headers. Most are housekeeping. A handful are security instructions.
The important thing to understand is that browsers ship with these protections turned off. Not because they are unsafe, but because switching them on can break sites that were not built with them in mind. So the browser waits to be told. If your server never says anything, the browser assumes the loose default.
Security headers are you saying something.
The five we check
There are more than five, but these are the ones that carry the weight.
- →HSTS tells the browser to only ever reach your site over HTTPS, even if someone types or clicks a plain http link.
- →Content Security Policy controls what a page is allowed to load and run, which is the strongest defence against injected scripts.
- →X-Frame-Options stops other sites putting yours inside a frame, which is the basis of clickjacking.
- →X-Content-Type-Options with the value nosniff stops the browser guessing at a file type and running something as script that was never meant to be one.
- →Referrer-Policy controls how much of your URL is passed to other sites when someone clicks away.
Why a header count can mislead you
Plenty of tools grade a site by counting headers and handing out a letter. That is a rough signal at best, and it can be unfair in both directions.
Hosted platforms often set the important ones for you. At the time of writing, several of the big ecommerce and site builders already send HSTS, nosniff and a framing rule with no action from the owner. A site can score badly on a checklist while being perfectly well defended, simply because the platform picked different headers than the checklist expected.
It also runs the other way. Sending a header is not the same as sending a good one. A CSP full of wildcards is a header, and it protects nothing.
If you only do one thing
X-Content-Type-Options: nosniff is the lowest-risk header on the list. It is a single value, there is nothing to tune, and it almost never breaks anything. If you are nervous about touching your server config, start there.
At the other end is Content Security Policy. It is the most valuable header and the one most likely to break your site, because a strict policy will happily block your own analytics, chat widget and embedded video along with the bad stuff. CSP wants a plan, a report-only run, and some patience. It is not a copy and paste job.
HSTS sits in the middle. It is genuinely valuable, but order matters. Certificate first, then force HTTPS everywhere, then HSTS. Never before.
A pitfall worth knowing about
Setting the same header in two places is a real and common problem. A plugin sets one, the server config sets another, and now the browser has two policies to reconcile. With CSP, browsers apply the most restrictive combination of everything they were sent, so two reasonable policies can add up to a site that will not load.
Pick one layer. Set them there. Do not sprinkle.
Where to start
The right method depends entirely on where your site lives. On a server you control, it is a config change. On a hosted platform, it ranges from a built-in settings panel to genuinely impossible.
Run a free check to see what your site sends today, then head to the fix guides for the steps that apply to your platform, including the honest ones about the platforms that will not let you.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to add security headers on your platform