Security Headers Explained: CSP, HSTS and Five Quick Wins

Why response headers punch above their weight

Every time someone visits your website, your server sends back a set of HTTP response headers alongside the page. A handful of these are instructions to the browser about what it may and may not do with your content: which scripts to run, whether the page can be framed by another site, whether to insist on HTTPS. Set them correctly and the visitor's own browser becomes part of your defence.

The appeal for a small business is the effort-to-value ratio. There is no software to buy and nothing to redesign; most headers are a few lines in a config file, deployable in under an hour. Yet they blunt real attacks, including cross-site scripting, clickjacking and the card-skimming scripts that have plagued small ecommerce sites for years. Run any UK small-business site through a scanner today and the most common grade is an F, purely because nobody ever set them.

HSTS: make HTTPS non-negotiable

Strict-Transport-Security (HSTS) tells the browser to refuse plain HTTP connections to your domain for a set period. Without it, a visitor who types your address without the https:// makes one insecure request first, and that request can be intercepted on hostile networks such as public Wi-Fi. With HSTS, the browser upgrades the connection itself before anything leaves the device.

The standard value is: max-age=31536000; includeSubDomains; preload. That is one year of enforcement, applied to subdomains, with eligibility for browsers' built-in preload lists. Two cautions before you copy it: be certain every subdomain you use (including webmail and staging) works over HTTPS, and treat the preload flag as near-permanent, because removal from browser preload lists takes months. If unsure, start without preload and a shorter max-age, then harden it once everything proves stable.

Content-Security-Policy: the big one

CSP is an allowlist of where your pages may load resources from. If a script is injected into your page, whether through a vulnerable plugin, a compromised third-party tag or a hijacked form, the browser checks it against your policy and blocks anything from an unapproved source. It is the single most effective header against cross-site scripting and payment-page skimming.

It is also the only header that can break your site, because analytics, fonts, embedded maps and tag managers all load from external domains that must be listed. The safe route is to deploy it as Content-Security-Policy-Report-Only first: the browser reports violations without blocking anything, you tidy the policy over a week or two, then switch to enforcement. A reasonable starting point for a simple site is: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; upgrade-insecure-requests, extended with the specific domains you actually use.

Five quick wins you can set today

These five are low-risk, take minutes, and rarely break anything.

• X-Content-Type-Options: nosniff — stops browsers second-guessing file types, which blocks a class of content-smuggling attacks.
• X-Frame-Options: SAMEORIGIN — prevents other sites embedding yours in an iframe for clickjacking; frame-ancestors in CSP is the modern equivalent, and setting both is fine.
• Referrer-Policy: strict-origin-when-cross-origin — other sites see only your domain, not full URLs that might carry customer or campaign data.
• Permissions-Policy: camera=(), microphone=(), geolocation=() — declares your site will never request these device features, so injected scripts cannot either.
• Cross-Origin-Opener-Policy: same-origin — isolates your pages from windows opened by other origins, closing off some cross-window attacks.

Copy-paste configs for common setups

Apache and LiteSpeed (.htaccess)

Most UK shared hosts, including Hostinger, run Apache or LiteSpeed and read an .htaccess file in your site root. Add these lines (mod_headers is enabled almost everywhere):

• 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=()"

Nginx

In your server block, then reload with nginx -s reload:

• 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;

Netlify, Cloudflare and similar platforms

Netlify reads a _headers file in your publish folder; list the path (/*) then each header indented beneath it. On Cloudflare, use Rules and response header modifications, or enable the managed security headers option. Vercel takes a headers block in vercel.json. Same headers, different wrapper.

Test it in two minutes

Go to securityheaders.com, enter your domain and press Scan. You get a letter grade from A+ to F and a table showing exactly which headers are present, missing or misconfigured. Mozilla's HTTP Observatory offers a second opinion with more detail on CSP quality. Both are free and safe to run against your live site.

• Scan before changing anything, and screenshot the grade as your baseline.
• Add the five quick wins and HSTS, then rescan; most sites jump from F to A immediately.
• Deploy CSP in report-only mode, refine it, then enforce it to chase the A+.
• Re-test after any redesign or new third-party tool, since new scripts often need policy updates.

An hour of configuration removes whole categories of risk and is one of the few security jobs with instant, visible proof of improvement. If you would rather have it done and verified for you, our team can handle it as part of routine site maintenance.