Three security headers most small business sites are missing, and why they matter

An estate agency in Manchester had a contact form on their site that, unknown to them, was leaking the full URL of the page someone had been viewing before they clicked through, including a search query with a client's address in it, straight into the analytics dashboard of an ad network embedded elsewhere on the page. Nothing was hacked. The site was simply missing a Referrer-Policy header, so the browser did what it does by default: handed over more information than necessary.

Permissions-Policy, Referrer-Policy, and X-Content-Type-Options are three separate headers that get grouped together because they tend to go missing together. Each closes a different, specific gap, and each is genuinely simple to fix once you know it's absent.

Permissions-Policy: controlling what your page is allowed to access

Permissions-Policy lets you explicitly state which browser features your page is permitted to use, things like the camera, microphone, geolocation, or autoplay. Without it set, the browser's defaults apply, which are often more permissive than a typical business site actually needs.

The risk shows up most clearly if your site ever embeds third-party content, an iframe, an embedded video, a chat widget, because without a Permissions-Policy header restricting what's allowed, that embedded content can potentially request access to device features your visitors never expected your website to need.

Referrer-Policy: controlling what gets shared when someone clicks a link

Every time someone clicks a link from your site to another, the browser can send the destination site information about where the click came from, called the referrer. By default, that can include the full URL of the page they were on, search terms, internal page identifiers, sometimes more than a business intends to share.

A Referrer-Policy header lets you control how much of that information gets passed on. Setting it to something like strict-origin-when-cross-origin means external sites only see your domain, not the specific page or query string, while same-site navigation still gets full referrer information for your own analytics.

X-Content-Type-Options: stopping the browser from guessing wrong

X-Content-Type-Options is the simplest of the three. Set to nosniff, it tells the browser to trust the file type your server declares for each resource rather than trying to guess it based on content. Without this header, some browsers will attempt to interpret a file as something other than what it's labelled as, which has historically been used to smuggle executable content disguised as an innocuous file type, like an image, past basic checks.

It's a small header with a narrow job, but it closes a class of attack that's existed since browsers started trying to be helpful about file type detection.

Why these three show up together so often

All three are response headers set at the server level, and most default web server and hosting configurations simply don't include them out of the box. A business that built its website through an agency three or four years ago is running whatever the agency's template shipped with at the time, and security headers have historically not been a standard line item in website builds, even good ones.

Where this sits in Cyber Essentials

Like the cross-origin headers, these three fall under CE2 Secure Configuration and are checked automatically rather than through self-assessment. They're typically ranked Low severity individually, but Cyber Essentials assessors look at the pattern as much as any single finding. A site missing five or six headers at once suggests nobody has ever specifically configured security headers, which is a fair conclusion for an assessor to draw and act on.

How to add them

All three are set in your server or CDN configuration, the same layer where you'd add the cross-origin headers covered separately. If you're running behind Cloudflare or a similar CDN, look for a custom headers or transform rules feature, which usually lets you add all three without touching your application code. If you manage your own server, they go in the same Nginx, Apache, or framework middleware configuration as your other security headers, so it's sensible to add the full set together rather than one at a time.

Frequently asked questions

Do these headers slow down my website? No, headers add a negligible amount of data to each response and have no measurable impact on page load speed.

Can I set these headers through my CMS, like WordPress, without touching server config? Some security plugins for WordPress and similar platforms can add headers without direct server access, though a CDN-level setting is usually more reliable and harder to accidentally undo with a plugin update.

What happens if I set Referrer-Policy too strictly? If you restrict it too much, your own analytics tools may lose useful information about which pages on your site visitors came from, so strict-origin-when-cross-origin is a sensible balance between privacy and useful data.

Will adding X-Content-Type-Options break any file uploads or downloads on my site? It's extremely unlikely, since it only takes effect if your server is sending an incorrect content type to begin with, which is something worth fixing regardless.

How do I check which of these headers I'm already missing? Browser developer tools show response headers under the Network tab for any page, or a scan will list all of them at once without needing to check page by page.

Run a free scan of your domain and your CE Readiness checklist will list every missing header by name, ready before your assessor asks: olimpio.io/free-scan