What are HTTP security headers — and which ones does your site actually need?

If you run a security scan on your site and it comes back with a wall of warnings about missing headers, the temptation is to either panic or ignore it entirely. Neither helps. Most of these are genuinely straightforward to fix — the tricky part is knowing which ones actually matter and why.

Strict-Transport-Security is the one I'd add first. It tells browsers to only ever connect to your site over HTTPS, even if someone types http:// or follows an old link. Without it, there's a class of attack on public WiFi where someone can intercept the initial unencrypted request before your site redirects to HTTPS. One header, five minutes to add, never think about it again.

For nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

X-Content-Type-Options: nosniff is the boring one that everyone should have. Browsers sometimes try to guess what type of file they've been served — a behaviour called MIME sniffing — which can be exploited if your site accepts file uploads. Setting this header tells the browser to just trust what the server says the file is. It's one line and the risk of not having it only goes up if you let users upload things.

X-Frame-Options prevents your pages from being embedded in iframes on other domains. The attack this protects against is clickjacking — your login page loaded invisibly inside someone else's site, with fake UI overlaid to trick users into clicking things they didn't mean to. DENY is the safest setting. If you need to allow specific origins, use the newer frame-ancestors directive in your Content Security Policy instead, which gives you more control.

Referrer-Policy is one most people skip because it sounds unimportant. When a user clicks a link from your site to another site, the browser sends a Referer header containing the full URL they came from. If your URLs contain anything sensitive — user IDs, session tokens, internal paths — those are being leaked to every external site your users navigate to. strict-origin-when-cross-origin is a sensible default that sends the origin but drops the path for cross-site requests.

Content Security Policy is the powerful one and also the annoying one. It lets you define exactly which scripts, styles, images and other resources are allowed to load on your page. Done properly, it stops XSS attacks even if an attacker manages to inject content — they still can't run arbitrary scripts because those scripts aren't on your allowlist.

The catch is that if you use third-party scripts (analytics, chat widgets, fonts, anything), you need to explicitly allow them, which turns into a bit of a project the first time. The way to approach it without breaking your site is to start in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'; ...

This logs violations without blocking anything. You can see exactly what would break, adjust the policy, then switch to enforcing it once you're confident.

Beyond HTTP headers, the email-related DNS records are just as important and often completely missed. SPF and DMARC together control whether other mail servers will accept email claiming to be from your domain. Without them, anyone can send phishing emails that appear to come from you. Your bank, your customers, anyone. The fix is adding a few DNS records — your email provider (Google Workspace, Postmark, whoever) will give you the exact values to add.

The headers themselves take an afternoon to add. CSP takes longer if you have a lot of third-party dependencies, but you can ship the others immediately and tackle CSP properly as a separate piece of work.

If you want to see where your site currently stands, I built SecURL for exactly this — paste a URL and get a graded report with everything ranked by priority. Free, no account needed.