Security Headers

What is a security header, and which ones actually matter?

The idea in one paragraph

Every time your server answers a request, it sends back the page plus a set of HTTP headers — metadata the browser reads before doing anything with the content. A security header is one of those lines whose job is to switch on a browser protection. The browser already knows how to defend your users against several common attacks; security headers are how you tell it to actually do so. Most are a single line of configuration, which makes them some of the highest-value, lowest-effort security you can add.

The ones that matter most

Content-Security-Policy (CSP)

The most powerful and the most involved. CSP defines an allowlist of where scripts, styles, images and other resources may load from. Done well, it is the strongest defense against cross-site scripting, because injected scripts are simply not on the list and do not run. Its common weakness is unsafe-inline, which allows inline scripts and quietly defeats much of the protection.

Strict-Transport-Security (HSTS)

Tells the browser to only ever connect to your site over HTTPS, even if someone types or clicks a plain http:// link. This shuts down protocol-downgrade attacks. A strong value looks like max-age=63072000; includeSubDomains.

X-Content-Type-Options

One value, nosniff, and you are done. It stops the browser from guessing (and getting wrong) the type of a file, which prevents a class of attacks where a benign-looking upload is treated as a script.

X-Frame-Options

Stops other sites from loading yours inside an invisible frame to trick your users into clicking things (clickjacking). SAMEORIGIN is the usual choice, or the modern frame-ancestors directive in your CSP.

Referrer-Policy

Controls how much of your URL is sent to other sites when a user clicks a link or loads a third-party resource. strict-origin-when-cross-origin is a sensible default that stops you leaking full URLs — which sometimes contain tokens or private paths.

The modern extras

Worth adding once the above are in place: Permissions-Policy to switch off browser features you do not use (camera, microphone, geolocation), and Cross-Origin-Opener-Policy to isolate your site from other windows. Both are Low or Info severity individually, but they are free and shrink your attack surface.

Why most sites are missing them

Frameworks rarely set these for you, so unless someone deliberately added them, they are simply absent. That is why a header check is one of the most consistently useful things a scan does — the fixes are easy, and the gaps are everywhere.

Check your headers

You cannot tell which headers you send by looking at your site — they are invisible to the page. An automated scan reads your actual responses and reports exactly which security headers are present, missing, or weakly configured. Scan your site and see your header gaps.

Related reading

FAQ

Which security header should I add first?
If you can only do a few quick ones, start with X-Content-Type-Options: nosniff, X-Frame-Options, HSTS and Referrer-Policy — each is essentially one line. Then take on Content-Security-Policy, which is the most powerful but needs more care.
Can security headers break my site?
A strict Content-Security-Policy can block legitimate scripts if it is too tight, which is why you roll CSP out in report-only mode first to see violations before enforcing. The simpler one-line headers rarely cause issues.
Do security headers replace other protections?
No — they are defense-in-depth. They make whole classes of attack harder and limit the damage when something else goes wrong, but they work alongside good coding, HTTPS and secret hygiene, not instead of them.