HTTP Security Headers Explained — Why They Matter for Your UK Website

The Security Layer Most Websites Ignore

When a browser visits your website, your server sends back not just the page content, but also a set of HTTP headers — invisible instructions that tell the browser how to behave. Most developers focus on getting the content right. Far fewer think about the security headers.

That's a mistake. HTTP security headers are one of the cheapest and most effective security improvements you can make to any website. Most take minutes to implement and protect against entire categories of attack.

Here's what each one does, why it matters, and what a website security scan will flag if you're missing them.

Content-Security-Policy (CSP)

**What it does:** Tells the browser exactly which sources of content are allowed to load on your page — which scripts, stylesheets, images, fonts, and frames are permitted and from which domains.

**Why it matters:** Without a CSP, if an attacker manages to inject malicious script into your page (via XSS or a compromised third-party service), the browser will happily execute it. A properly configured CSP tells the browser to only run scripts from sources you explicitly trust. An injected script from an unknown domain gets blocked before it executes.

**What a weak or missing CSP looks like:** Either the header is absent entirely, or it's set to `Content-Security-Policy: default-src *` — which effectively allows everything and provides no protection at all.

**The tradeoff:** CSP is the most powerful security header and also the most complex to configure correctly. Getting it right on a site with many third-party scripts requires care. But even a basic, restrictive policy is significantly better than none.

Strict-Transport-Security (HSTS)

**What it does:** Tells the browser that your site should only ever be accessed over HTTPS — and to remember this instruction for a specified period (typically one year).

**Why it matters:** Without HSTS, even if your site supports HTTPS, a visitor might initially connect over HTTP and be subject to a downgrade attack — where an attacker intercepts the connection before it can upgrade to HTTPS. HSTS eliminates this window.

**Key configuration:** The `max-age` directive sets how long the browser remembers the instruction. `includeSubDomains` extends the policy to all subdomains. `preload` submits your domain to a browser-maintained list of HSTS-only domains.

**Common mistake:** Setting a very short `max-age` (like 300 seconds), which means the protection expires quickly and provides little real defence.

X-Frame-Options

**What it does:** Controls whether your website can be embedded in an iframe on another site.

**Why it matters:** Clickjacking attacks work by embedding your site transparently inside an attacker's page, then tricking visitors into clicking on things they can't see — buttons on your site that the attacker has layered under innocent-looking content. X-Frame-Options set to `DENY` or `SAMEORIGIN` prevents your site from being embedded in this way.

**Modern alternative:** The `frame-ancestors` directive in Content-Security-Policy provides more granular control. But X-Frame-Options is still widely supported and worth including for compatibility.

X-Content-Type-Options

**What it does:** Tells the browser not to try to guess (or "sniff") the content type of a response — to trust the `Content-Type` header you send instead.

**Why it matters:** Browsers will sometimes try to interpret files in a way that differs from what the server declares. This can lead to situations where an uploaded file containing malicious script gets executed as JavaScript even though the server labelled it as something else. Setting `X-Content-Type-Options: nosniff` prevents this.

**Effort to implement:** Minimal. One line of server configuration. No downside.

Referrer-Policy

**What it does:** Controls how much information about the current page URL is sent when a visitor follows a link to another site.

**Why it matters:** Without a Referrer-Policy, when someone on your site clicks a link to an external site, the full URL they came from — including any query parameters — gets sent to that external site as the `Referer` header. If your URLs contain sensitive information (session tokens, user IDs, search terms), this leaks that data to third parties.

**Recommended setting:** `Referrer-Policy: strict-origin-when-cross-origin` sends only the origin (domain) when making cross-origin requests, and nothing when downgrading from HTTPS to HTTP.

Permissions-Policy

**What it does:** Controls which browser features your site can use — camera, microphone, geolocation, payment APIs, and more.

**Why it matters:** If a third-party script embedded on your site tries to access the user's camera or microphone, a Permissions-Policy header can block that access before it even gets requested. This limits the blast radius of a compromised third-party integration.

**Example:** `Permissions-Policy: camera=(), microphone=(), geolocation=()` disables all three features across your entire site.

How to Check Your Headers

You can check your site's security headers using free tools like securityheaders.com, or by opening your browser's developer tools and inspecting the Response Headers tab on any request to your site.

Better still, include header checks as part of a comprehensive security scan. Yrzo AI's automated scans check all of these headers, identify exactly which are missing or misconfigured, and give you specific remediation guidance for your particular setup — whether you're running on Apache, Nginx, Cloudflare, or a hosted platform.

The Bottom Line

Security headers are the easiest wins in web security. Most are single lines of server configuration. None of them require code changes to your application. And together they block entire categories of attack that cost businesses real money and real reputational damage every year.

If a security scan of your site comes back flagging missing headers, that's the first thing to fix — before anything else. Fast, cheap, and high impact.