Blog · 5 November 2026 · 8 min read

HTTP security headers in plain English

Every security scanner – including our free quick scan – tells small-business websites they have “missing security headers”. It sounds alarming, but it usually comes down to six lines of configuration you can add in an hour. This article explains what each one does, what it protects your visitors from, and how to enable it without breaking your site.

What an “HTTP header” actually is

When a browser fetches your page, the server sends back more than the content. It also sends a short label: a dozen or so lines such as “this is HTML”, “cache it for an hour”, “server: nginx”. Those are headers. Visitors never see them, but the browser reads and obeys them. Some are security instructions: “don’t let anyone show this page inside a frame”, “only ever talk to me over an encrypted connection”.

When those instructions are absent, the browser falls back to its most permissive defaults – the ones from the 1990s. The site still works, but your visitors are more exposed to a handful of classic attacks. That is why scanners (Mozilla Observatory, securityheaders.com, Lighthouse, Webskan) deduct points for missing headers, and why corporate clients and auditors increasingly ask about them.

The six headers that matter most

Two of them are worth understanding properly

HSTS – “always the padlock”

Most sites today have a certificate and a redirect from http:// to https://. The catch is that the first, unencrypted request still happens – and on an open network someone can intercept it before the redirect kicks in. HSTS tells the browser to remember: “from now on, I only visit this domain over HTTPS”, so after the first visit the unencrypted request is never sent at all.

A typical value is max-age=31536000; includeSubDomains (one year, including subdomains). Before enabling it, make sure every subdomain you use (shop., portal., webmail) works over HTTPS – otherwise it will be unreachable for a year for anyone who has visited your main site once. If you are not sure, start without includeSubDomains and with a shorter time, e.g. max-age=86400.

CSP – the biggest win and the biggest risk

Content-Security-Policy is the only header of the six that genuinely has to be tailored to your site. It tells the browser where scripts, styles, images and fonts may be loaded from. Set up well, it blocks the most dangerous class of attacks on business websites: a foreign script injected through a vulnerable plugin or a hijacked account that swaps your bank details or siphons off what customers type into forms.

Set up badly, it blocks your own chat widget, map, ad pixel or gallery, and the site “stops working” with no message to the visitor. So the order is always the same:

1. List where your site loads resources from: your own domain, Google Fonts, Google Analytics / Tag Manager, maps, chat, YouTube, your payment provider.
2. Deploy the policy in report-only mode (Content-Security-Policy-Report-Only). It blocks nothing; it just prints in the browser console what would have been blocked.
3. Click around the site on a phone and a desktop, adjust the list of sources until the console is clean.
4. Only then rename the header to Content-Security-Policy.

If a full policy is too much at once, a sensible first step is just the frame-ancestors 'self' directive (the modern replacement for X-Frame-Options) plus upgrade-insecure-requests. That alone improves scanner scores and cannot break anything.

How to enable them – the three most common setups

1. Site behind Cloudflare (or another CDN)

The easiest case. In the Cloudflare dashboard: Rules → Transform Rules → Modify Response Header, add static headers for the whole domain. HSTS has its own switch under SSL/TLS → Edge Certificates. Changes apply immediately and you never touch the server.

2. WordPress on shared hosting

Two routes. A plugin (e.g. “Headers Security Advanced & HSTS WP”, or the headers module in plugins like Really Simple Security) – convenient, but one more plugin to maintain. Or a few lines in .htaccess (Apache / LiteSpeed, i.e. most shared hosts):

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

Back the file up first. If the site shows a 500 error after saving, your host doesn’t have the headers module enabled – use a plugin or ask support.

3. Your own server (nginx)

Inside the server block:

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

The word always matters: without it nginx omits the headers on error pages, and scanners notice.

Two headers worth removing

Scanners also look the other way: at what the server gives away. Headers like Server: Apache/2.4.29 (Ubuntu) or X-Powered-By: PHP/7.4.3 tell an attacker exactly which vulnerabilities to try. The bare name (“nginx”, “cloudflare”) is harmless; the version number is not, especially an old one. In PHP it’s expose_php = Off, in Apache ServerTokens Prod, in nginx server_tokens off;. On shared hosting you often can’t change this yourself – ask support, or put a CDN in front of the server.

What not to worry about

• “If I enable headers, the site will break.” Four of the six (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) are safe on virtually any business website. HSTS needs one check (is everything on HTTPS?). Only CSP needs testing.
• “This only matters for banks.” Clickjacking and injected scripts hit ordinary business sites precisely because they are less protected. The common scenario is a swapped bank account number on an invoice page, or a contact form quietly sending a copy of the data somewhere else.
• “I have SSL, so I’m safe.” A certificate encrypts the connection. It says nothing to the browser about what may be done with your page once it has loaded – that is what headers are for.