Security headers explained: what they do and how to get an A grade
Security headers are free, take an hour to configure, and close entire categories of attack. Most sites score badly on them. Here's what each one does.
Every time a browser loads your site, your server can send instructions alongside the content that shape what the browser is allowed to do. Can scripts load from other domains? Is the page allowed inside someone else's iframe? Should the browser ever use plain HTTP? Those instructions are security headers, they cost nothing to send, and they're the difference between a hacking attempt being blocked and succeeding.
The headers that matter
Content-Security-Policy (CSP)
The big one, and the hardest to get right. CSP whitelists where scripts, styles, images and frames may come from. Its headline job is neutralising cross-site scripting (XSS) — still the most common web vulnerability — because even if an attacker injects a script tag into your page, the browser refuses to run anything that didn't come from your approved list. A strict CSP with hash-locked scripts is genuinely strong. A CSP that ends in 'unsafe-inline' everywhere is theatre.
Strict-Transport-Security (HSTS)
Tells browsers: only ever reach this site over HTTPS, for the next two years, no exceptions. Without it, the first request of every visit can be downgraded to plain HTTP by anyone on the same network — the open coffee shop problem. HSTS closes it, and it's a one-line header.
X-Frame-Options / frame-ancestors
Stops your pages being embedded in other sites' frames, which kills clickjacking — attacks where a real button on your site is hidden under a fake one on somebody else's.
X-Content-Type-Options
Stops browsers second-guessing file types. nosniff means an uploaded file served as text can't be reinterpreted as an executable script.
Referrer-Policy and Permissions-Policy
The first controls how much URL information leaks to other sites when people follow links away from you. The second switches off browser features your site doesn't use — camera, microphone, geolocation — so injected content can't abuse them either.
Why most sites fail this
Almost no hosting control panels send any of these by default, and the scoring services (the Mozilla Observatory and securityheaders.com grade sites A to F) reflect that. Two things typically hold sites back: nobody owns the job, and CSP is genuinely fiddly on template-based sites — every inline script and third-party widget needs accounting for, or the site visibly breaks.
The pragmatic path is to deploy CSP in report-only mode first: the browser reports what it would block without blocking anything. You review the report, add the legitimate exceptions, and tighten over a week. Nothing breaks, and you end up with a policy that reflects how your site really works.
What a good result looks like
A proper configuration is a handful of lines in your web server config: a strict CSP, HSTS with a two-year max-age, the frame, content-type, referrer and permissions headers. No code changes, no redesign, no performance cost — and it visibly demonstrates to anyone who checks (including security-minded customers and procurement departments) that the site is professionally run.
Grade your site in seconds with our free security headers tool — it checks every header above, explains what's missing, and shows the exact fix. If your grade is uncomfortable, the fix is usually an hour of config work, which we fold into any site build or take on standalone.
Check your own site in seconds with our free security headers tool — and if you’d rather hand the whole job over, talk to us.
Found this useful? Share on LinkedIn · Email it to someone