Security Guides7 min read4 October 2026

How to Fix Missing Security Headers on Your UK Website (And Why They Matter)

Security headers protect against XSS, clickjacking and data theft. This guide explains what each one does and how to add them to your UK business website.

By Yrzo AI — UK cybersecurity specialists

Security headers are HTTP response headers that instruct browsers how to behave when loading your website. They are one of the lowest-effort, highest-impact security improvements you can make — a few lines in your server configuration that activate browser-level protections against some of the most common attack categories.

They are also among the most commonly missing. In automated scans of UK business websites, missing or misconfigured security headers appear in the majority of reports. They're not a vulnerability in themselves — they don't open a hole an attacker can directly exploit. But their absence removes defensive layers that would otherwise contain or prevent successful attacks.

This guide covers the six headers that matter most, what each one protects against, and how to add them to the most common UK hosting configurations.

1. Content-Security-Policy (CSP)

**What it does**: CSP defines which sources of content your browser is allowed to load. JavaScript, CSS, images, fonts, iframes — each can be restricted to trusted domains only. This is the primary defence against cross-site scripting (XSS) attacks.

**Why it matters**: XSS attacks inject malicious JavaScript into your page. Without CSP, that script executes with full access to the page — it can steal session cookies, capture keystrokes, redirect users, or exfiltrate form data. With a strong CSP, even if an attacker successfully injects a script, it can't load from an external attacker-controlled domain and may be blocked entirely.

**A basic CSP for a simple website**:

``` Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; ```

This tells the browser: only load scripts, styles, images, and fonts from this same domain. `'unsafe-inline'` for styles is a common concession for sites that use inline CSS. For script, avoid `'unsafe-inline'` where possible — it significantly weakens CSP.

For sites using Google Analytics, fonts, or third-party tools, you'll need to whitelist those domains:

``` Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https://*.google-analytics.com; font-src 'self' https://fonts.gstatic.com; ```

**Implementation note**: CSP can break things. Start with `Content-Security-Policy-Report-Only` to test without enforcing — violations are logged to your browser console without blocking anything. Once you've verified nothing breaks, switch to `Content-Security-Policy`.

2. Strict-Transport-Security (HSTS)

**What it does**: HSTS tells browsers to always connect to your site over HTTPS, even if a user types `http://` or clicks an old HTTP link. It prevents SSL stripping attacks, where a man-in-the-middle downgrades your HTTPS connection to HTTP before the encryption can establish.

**Why it matters**: Even if your server redirects HTTP to HTTPS, there's a brief window during that redirect where an attacker on the same network (a coffee shop Wi-Fi) can intercept the unencrypted initial request. HSTS closes that window by making the browser refuse to send any request over plain HTTP after the first visit.

**The header**:

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

`max-age=31536000` tells the browser to remember this for one year. `includeSubDomains` applies the policy to all subdomains. `preload` opts you into browser preload lists — browsers ship with a hardcoded list of HSTS sites that get the protection from the very first visit.

**Prerequisite**: Your entire site and all subdomains must serve valid HTTPS before adding `includeSubDomains` or `preload`. If any subdomain doesn't have SSL, HSTS will break it.

3. X-Frame-Options

**What it does**: Prevents your website from being embedded in an iframe on another domain. Protects against clickjacking attacks, where an attacker overlays your page inside a transparent iframe on their site to trick users into clicking elements they can't see — confirming a payment, changing account settings, granting permissions.

**The header**:

``` X-Frame-Options: DENY ```

Or, if your own site needs to embed pages in iframes (unusual but valid):

``` X-Frame-Options: SAMEORIGIN ```

`DENY` prevents embedding anywhere. `SAMEORIGIN` allows embedding only from your own domain.

**Note**: CSP's `frame-ancestors` directive supersedes X-Frame-Options in modern browsers, but X-Frame-Options is still needed for older browser compatibility. If you have CSP, add both.

4. X-Content-Type-Options

**What it does**: Prevents browsers from MIME-type sniffing — guessing what type of file a response is based on its content rather than the declared `Content-Type` header. Without this header, a browser might interpret a text file uploaded to your server as HTML or JavaScript and execute it.

**The header**:

``` X-Content-Type-Options: nosniff ```

**Why it matters**: If your site allows file uploads, an attacker might upload a file with a `.txt` extension but containing JavaScript. If your server serves it with a `text/plain` content type but the browser MIME-sniffs it and decides it looks like JavaScript, it executes. `nosniff` tells the browser to trust the declared content type and nothing else.

5. Referrer-Policy

**What it does**: Controls how much referrer information your browser sends when a user clicks a link from your site to another site. By default, browsers may send the full URL — including any query parameters that could contain sensitive data (search terms, session identifiers, user IDs).

**The header**:

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

This sends the full URL when navigating within your own site (useful for analytics), but only the origin (e.g., `https://yoursite.co.uk`) when navigating to external sites. Sensitive query parameters aren't leaked.

6. Permissions-Policy

**What it does**: Controls which browser features (camera, microphone, geolocation, payment APIs) your page — and embedded third-party content — is allowed to use. Prevents malicious third-party scripts from silently activating a user's camera or accessing their location.

**A conservative policy for a standard business website**:

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

This disables all four for any content on your page. If your site legitimately uses one (a contact form with geolocation for a store finder), add your own origin: `geolocation=(self)`.

How to Add Headers: Common UK Hosting Configurations

Apache (.htaccess)

Most shared hosting in the UK uses Apache. Add to your `.htaccess` file:

``` <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header always set X-Frame-Options "DENY" Header always set X-Content-Type-Options "nosniff" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()" </IfModule> ```

Nginx

Add inside your `server {}` block:

```nginx add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Frame-Options "DENY" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; ```

Cloudflare

If your site is proxied through Cloudflare (common for UK businesses for DDoS protection and CDN), you can add headers via Transform Rules in the Cloudflare dashboard (Security → Transform Rules → Modify Response Header) without touching your server configuration.

WordPress

For WordPress sites, a plugin like Headers Security Advanced & HSTS WP or Solid Security (formerly iThemes Security) can add security headers without server configuration access. Alternatively, add the headers directly to `functions.php` or your theme's header code — but server-level headers are preferable as they apply to all responses, not just WordPress-generated pages.

Verifying Your Headers

After adding headers, verify them at securityheaders.com (a free third-party tool) or by checking your browser's developer tools (Network tab, click any response, examine the Response Headers section).

A Yrzo AI automated security scan includes a full check of all HTTP response headers across your site, with specific findings and exact fix instructions for any that are missing or misconfigured. Part of a 44-check assessment from £399 at yrzoai.dev.

Find out if your website has these vulnerabilities

Yrzo AI runs 44 automated security checks and delivers a full report in under 20 minutes. Starting from £399.

Scan your website →