5 Security Headers Your Website Is Probably Missing

Content-Security-Policy, HSTS, and three other HTTP headers that cost a config change and close off entire categories of attack — explained without the jargon.

HTTP security headers are one of the highest-leverage things a small site can ship: no code changes, no new dependencies, usually a handful of lines in a config file — and they close off entire categories of attack. Most sites we’ve looked at are missing at least two or three of the following five.

1. Content-Security-Policy (CSP)

CSP tells the browser which sources of scripts, styles, images and other resources are allowed to load on your page. Without it, if an attacker manages to inject a <script> tag anywhere — a comment field, a URL parameter reflected back into the page — the browser will happily execute it. A CSP header can block that outright, even if the injection succeeds.

Content-Security-Policy: default-src 'self'; script-src 'self'

This is the header most worth doing properly, and also the easiest to get wrong on a first pass if your site loads scripts from several third-party domains — start in Content-Security-Policy-Report-Only mode to see what would have been blocked before you enforce it.

2. Strict-Transport-Security (HSTS)

HSTS tells browsers “never load this site over plain HTTP, even if someone types http:// or clicks an old link — go straight to HTTPS.” Without it, there’s a brief window on every first visit where a network attacker could intercept the initial HTTP request before the redirect to HTTPS happens.

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

3. X-Content-Type-Options

Without this header, some older browsers will try to “sniff” a file’s type from its content rather than trusting the Content-Type header — which can let a file uploaded as an image get executed as a script in the wrong context. One line shuts that off entirely.

X-Content-Type-Options: nosniff

4. Referrer-Policy

By default, when someone clicks a link from your site to another one, the browser can send the full URL of the page they came from — including query parameters, which sometimes contain things like session tokens or search terms you didn’t mean to leak. A sane referrer policy trims that down.

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

5. Permissions-Policy

This header lets you explicitly turn off browser features your site doesn’t use — camera, microphone, geolocation, payment APIs — so that even if a third-party script embedded on your page tries to access them, the browser refuses.

Permissions-Policy: camera=(), microphone=(), geolocation=()

Checking your own site

When we pointed SecurityForge at our own homepage while building it, it flagged exactly the headers you’d expect a small site to be missing — CSP and HSTS among them. That’s a genuinely common starting point, not a special failure; most sites ship without them until someone goes looking.

You can check any page’s headers the same way: paste a URL into SecurityForge and it reports which of these five are present, which are missing, plus a few other checks (HTTPS usage, mixed content, insecure form actions). If you’re on Cloudflare Pages, the fix is usually a _headers file in your project root with the headers you want applied, no server code required.

None of these five headers require touching your application code — they’re configuration, which makes them some of the cheapest security wins available to a small team.