Website Security Headers: A Quick Win for Better Protection

Your website might look polished and professional, but beneath the surface, it could be broadcasting an open invitation to attackers. Security headers are HTTP response headers that instruct browsers how to behave when handling your site's content, and they are one of the most effective — and most overlooked — defences against common web attacks like cross-site scripting (XSS), clickjacking, and data injection.

For UK businesses, where GDPR compliance demands that you take appropriate technical measures to protect user data, properly configured security headers are not a luxury — they are a baseline requirement. Yet a scan of typical UK business websites reveals that the majority are missing critical headers, leaving their visitors and their data unnecessarily exposed.

This guide covers every security header you should implement, explains what each one does and why it matters, provides practical implementation guidance, and shows you how to test your configuration using tools like securityheaders.com.

Content-Security-Policy (CSP)

Content-Security-Policy is the most powerful and most complex security header available. It controls which resources (scripts, stylesheets, images, fonts, frames, and more) the browser is allowed to load on your page. A well-configured CSP is the single most effective defence against cross-site scripting (XSS) attacks — the most common web application vulnerability in the world.

XSS attacks work by injecting malicious JavaScript into your web pages. Without a CSP, the browser has no way to distinguish between your legitimate scripts and an attacker's injected code — it simply executes everything. With a CSP, you explicitly declare which script sources are trusted, and the browser blocks everything else.

A basic CSP for a typical UK business website might look like this: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none';

This policy allows scripts only from your own domain and Google Tag Manager, stylesheets from your domain and Google Fonts (with inline styles permitted), images from your domain and any HTTPS source, fonts from Google's font CDN, and blocks your site from being framed by anyone. Every other resource type defaults to your own domain only.

Strict-Transport-Security (HSTS)

HTTP Strict Transport Security tells browsers to only communicate with your website over HTTPS, even if a user types http:// or clicks an HTTP link. Without HSTS, there is a brief window during the initial HTTP-to-HTTPS redirect where an attacker on the same network (in a coffee shop, hotel, or shared workspace) can intercept the unencrypted request through a man-in-the-middle attack.

The recommended HSTS header is: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This tells the browser to remember for one year (31,536,000 seconds) that your site should only be accessed over HTTPS, to apply this rule to all subdomains, and that you consent to being included in browser preload lists. The preload directive is particularly powerful — once your domain is added to the HSTS preload list (maintained by Chrome and used by all major browsers), browsers will never even attempt an HTTP connection to your site, eliminating the first-visit vulnerability entirely.

X-Frame-Options

X-Frame-Options controls whether your site can be embedded in an iframe on another website. This is the primary defence against clickjacking attacks, where an attacker loads your site in an invisible iframe and tricks users into clicking buttons they cannot see — potentially authorising payments, changing account settings, or performing other sensitive actions.

The recommended setting is: X-Frame-Options: DENY

This prevents your site from being framed by any other site (including your own). If you need to frame your own content (for example, embedding a form on a subdomain), use SAMEORIGIN instead, which allows framing only from the same domain.

Note that the CSP frame-ancestors directive provides more granular control than X-Frame-Options and is the modern replacement. However, since some older browsers do not support frame-ancestors, it is best practice to set both headers for maximum compatibility.

X-Content-Type-Options

This simple but important header prevents browsers from attempting to guess (or “sniff”) the content type of a response. Without it, a browser might interpret a file that claims to be an image as executable JavaScript if the content looks like code — a technique attackers use to bypass security controls.

The header is straightforward: X-Content-Type-Options: nosniff

There is only one valid value, and there is no reason not to set it. It prevents MIME-type confusion attacks with zero risk of breaking your site's functionality.

Referrer-Policy

When a user clicks a link on your website to visit another site, the browser normally sends a Referer header containing the full URL of the page they came from. This can leak sensitive information — particularly if your URLs contain session tokens, user IDs, search queries, or other private data.

The recommended setting for most UK business websites is: Referrer-Policy: strict-origin-when-cross-origin

This sends the full URL as a referrer for same-origin requests (within your own site), sends only the origin (domain name without the path) for cross-origin requests over HTTPS, and sends nothing at all if navigating from HTTPS to HTTP. This strikes a good balance between privacy and functionality — analytics tools like Google Analytics still receive enough information to track referral sources, but detailed URL paths are not leaked to third parties.

Permissions-Policy

Permissions-Policy (formerly Feature-Policy) controls which browser features and APIs your website is allowed to use. This prevents malicious scripts from accessing sensitive device capabilities like the camera, microphone, geolocation, or payment APIs without your explicit permission.

A strong Permissions-Policy for a typical UK business website: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()

This disables all these capabilities entirely. If your site needs any of them (for example, geolocation for a store finder feature), you can selectively enable them: geolocation=(self) allows your own site to use geolocation but prevents any embedded third-party content from accessing it.

Security Header	Primary Protection	Recommended Value	Risk If Missing
Content-Security-Policy	Cross-site scripting (XSS)	Customised per site (whitelist approach)	Critical — XSS is the #1 web vulnerability
Strict-Transport-Security	Man-in-the-middle / protocol downgrade	max-age=31536000; includeSubDomains; preload	High — enables interception on public Wi-Fi
X-Frame-Options	Clickjacking	DENY or SAMEORIGIN	Medium — clickjacking can authorise actions
X-Content-Type-Options	MIME-type confusion attacks	nosniff	Medium — can enable code execution
Referrer-Policy	URL / data leakage to third parties	strict-origin-when-cross-origin	Low to medium — privacy concern
Permissions-Policy	Unauthorised API / device access	Disable unused features	Medium — camera/mic/location abuse

How to Implement Security Headers

The implementation method depends on your web server or hosting platform. Here are the most common approaches for UK businesses.

For IIS (Internet Information Services), which is common for .NET applications hosted on Windows Server, add the headers in your web.config file within the <system.webServer><httpProtocol><customHeaders> section. Each header is added as a <add name="Header-Name" value="header-value" /> element.

For Apache, add the headers to your .htaccess file or virtual host configuration using the Header set directive. For example: Header set X-Content-Type-Options "nosniff". Ensure the mod_headers module is enabled.

For Nginx, add the headers to your server block using the add_header directive. For example: add_header X-Content-Type-Options "nosniff" always;. The always parameter ensures headers are sent even on error responses.

For Cloudflare, you can add security headers through Transform Rules in the dashboard, or through Cloudflare Workers for more complex logic. Cloudflare also automatically adds some security headers if you enable their security features.

For Azure App Service, add the headers through the web.config file (for .NET apps) or through application code for other runtimes. Azure Front Door and Azure CDN also support adding custom response headers through rules engine.

Security Headers and SEO

A common concern among UK businesses is whether security headers affect search engine rankings. The short answer is: yes, but positively.

Google has confirmed that HTTPS is a ranking signal, and HSTS strengthens your HTTPS implementation. Beyond that, Google's Core Web Vitals and page experience signals reward sites that provide a secure, trustworthy experience. While individual security headers are not direct ranking factors, the security posture they create contributes to the overall trust signals that search engines evaluate.

More importantly, security headers protect against attacks that can devastate your SEO. A successful XSS attack can inject spam links, redirect visitors to malicious sites, or deface your pages — all of which will trigger Google penalties that can take months to recover from. A clickjacking attack on your site can result in Google flagging your domain as unsafe, causing a dramatic drop in search visibility. Preventing these attacks through security headers is far easier than recovering from them.

Advanced Headers and Emerging Standards

Beyond the core six headers, several additional headers are worth considering for UK business websites that handle sensitive data or require a particularly strong security posture.

Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Opener-Policy (COOP) provide additional isolation for your pages, preventing cross-origin resources from accessing your page's data. These are required to enable powerful features like SharedArrayBuffer and high-resolution timers, and they provide defence against Spectre-class attacks.

Cross-Origin-Resource-Policy (CORP) controls which origins can load your resources (images, scripts, stylesheets). Setting same-origin prevents other sites from hotlinking your assets, reducing bandwidth costs and preventing your content from being used in attacks against other sites.

Clear-Site-Data is useful during logout flows, instructing the browser to clear cached data, cookies, and storage associated with your domain. This is particularly important for UK businesses handling personal data under GDPR, as it ensures no residual data remains in the browser after a user ends their session.

Building a Security Headers Implementation Plan

Do not try to implement all security headers simultaneously. Take a phased approach that minimises the risk of breaking your site.

Phase 1 (immediate, zero risk): Implement X-Content-Type-Options (nosniff), X-Frame-Options (DENY), and Referrer-Policy (strict-origin-when-cross-origin). These headers have no risk of breaking functionality and provide immediate protection.

Phase 2 (within one week): Implement Strict-Transport-Security with a short max-age initially (86400 seconds = one day), test thoroughly, then increase to the full year. Implement Permissions-Policy to disable unused browser APIs.

Phase 3 (two to four weeks): Deploy Content-Security-Policy in report-only mode. Analyse violation reports for two weeks, refine the policy, then switch to enforcement mode. This is the most complex header and benefits from careful, iterative implementation.