The security headers your site is probably missing

Security headers are the cheapest protection you're not using. They're a few lines in your server config that tell the browser how to defend your visitors — and each one shuts down a whole category of attack. Most sites I scan are missing at least half of them, usually because nobody ever told the server to send them.

Quick primer, in case the term is new: every time your site answers a request, it sends back a set of response headers — instructions the browser reads before it shows anything. Security headers are the subset that say "here's what you're allowed to do, and here's what you must refuse." Set them once, and every visitor is protected on every page.

Here are the ones that carry their weight.

Strict-Transport-Security (HSTS)

Forces every connection to your site over HTTPS, and remembers the rule so the browser never even tries plain HTTP again.

Without it, there's a window — that first request, or a stray http:// link — where an attacker on the same network can intercept the connection and downgrade it to unencrypted. HSTS closes that window. Once a browser has seen the header, it refuses to talk to your domain insecurely, full stop.

Strict-Transport-Security: max-age=31536000; includeSubDomains

One caveat worth respecting: only send it once you're sure HTTPS works everywhere, including subdomains. The whole point is that the browser will obey it stubbornly.

Content-Security-Policy (CSP)

The big one, and the hardest to get right. CSP tells the browser exactly which sources of scripts, styles and images it's allowed to load — and to refuse everything else.

This is your main defense against cross-site scripting (XSS): if an attacker manages to inject a <script> into your page, a good CSP means the browser simply won't run it, because it didn't come from an approved source. It's the difference between a defaced comment and a stolen session.

It's fiddly because you have to enumerate what your own site legitimately loads, and third-party widgets complicate that. The sane way to start is in report-only mode — the browser tells you what would have been blocked without actually blocking it — then tighten until it's clean, then enforce.

X-Content-Type-Options: nosniff

Short, boring, and you want it. It stops the browser from second-guessing the type of a file and "sniffing" it into something executable. Without it, a file you serve as harmless data can be coaxed into running as a script. One fixed value, no downside:

X-Content-Type-Options: nosniff

X-Frame-Options / frame-ancestors

Stops other sites from loading yours inside an invisible frame and tricking your users into clicking things they can't see — an attack called clickjacking. If your bank's "confirm transfer" button is sitting under a fake "play video" overlay, this is the header that was missing.

Modern CSP handles this with frame-ancestors, but X-Frame-Options: DENY (or SAMEORIGIN if you frame your own pages) still works everywhere and is worth keeping.

Referrer-Policy

Controls how much of your URL gets handed to other sites when a visitor clicks a link out. That matters more than it sounds: if your URLs contain things like reset tokens or session identifiers, a leaky referrer policy quietly ships them to whatever you linked to. A reasonable default:

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Lets you switch off browser features your site doesn't use — camera, microphone, geolocation. If you're not a video-call app, denying camera access means a script injected into your page can't reach for it either. It's defense in depth: one more capability an attacker doesn't get for free.

One to not bother with

If an old tutorial tells you to add X-XSS-Protection, skip it. The browser feature it controlled has been removed from modern browsers, and in some old cases it introduced bugs of its own. CSP replaced it. Sending it does nothing useful — a small reminder that "more headers" isn't the goal; the right headers are.

How to see which you're missing

You don't need a tool to start. Open your site, press F12, go to the Network tab, click the main document request, and read the Response Headers. Everything above should be there. Whatever's absent is a gap.

If you'd rather not squint at devtools on every page, that's part of what a scan is for — it checks these across your site and tells you, in plain terms, which headers are missing and what each one would have protected. They cost nothing to add and an afternoon to get right. There are very few security wins that cheap.