Security Headers in Plain Language
By CodexierPublished 4 min read
Security headers are short instructions your web server sends with every page, telling the browser how to behave: always use HTTPS, only run scripts from these places, do not let other sites put this page in a frame. They cost nothing, take little time to add, and close common attacks such as clickjacking and many forms of script injection. This guide explains the headers that matter in plain language, and how to add them without breaking payment widgets, analytics or embedded maps.
What security headers do
The mechanism is simple: the browser is the last line of defence between your site and the visitor. If an attacker manages to inject a script through a vulnerable plugin, a strict policy can stop the browser from running it. If someone tries to load your login page inside an invisible frame on their site, a framing header makes the browser refuse. Under GDPR you must take appropriate technical measures to protect personal data, and headers are among the cheapest measures available.
HSTS and HTTPS
Strict-Transport-Security, or HSTS, tells the browser to only ever connect to your site over HTTPS, for a set period. Without it, a visitor typing your address on a public Wi-Fi network can be intercepted during the first unencrypted request, before the redirect to HTTPS happens.
- Make sure every page and subdomain works over HTTPS first. Our guide to SSL certificates and HTTPS covers that.
- Start with a short max-age, such as one day, and check that nothing breaks.
- Increase to a long period, typically one or two years.
- Add includeSubDomains only when you are sure all subdomains support HTTPS, including old ones like a mail or shop subdomain.
Content Security Policy
Content-Security-Policy, or CSP, is a list of sources the browser may load scripts, styles, images, fonts and frames from. Anything not on the list is blocked. It is the most powerful header and the one most likely to break something, because modern sites load code from many places: analytics, cookie banners, chat widgets, maps, and payment providers such as Klarna, Stripe or a Swish checkout.
- List every third-party service the site uses before writing the policy.
- Start with default-src 'self' and add each needed source explicitly.
- Avoid 'unsafe-inline' for scripts where possible; it removes much of the protection.
- Test checkout, login, forms and consent banners specifically, since these break most often.
Framing, sniffing and referrer headers
| Header | What it prevents | Typical safe value |
|---|---|---|
| X-Frame-Options, or CSP frame-ancestors | Your pages being embedded in someone else's site to trick clicks (clickjacking) | SAMEORIGIN, or frame-ancestors 'self' |
| X-Content-Type-Options | The browser guessing a file type and running an uploaded file as a script | nosniff |
| Referrer-Policy | Full URLs, which can contain personal data, leaking to other sites | strict-origin-when-cross-origin |
| Permissions-Policy | Embedded content using camera, microphone or location without need | Turn off features you do not use |
These four rarely break anything. The exception is framing: if you embed your own pages in another domain you control, allow that domain explicitly.
Testing before enforcing
CSP has a report-only mode: the browser reports what would have been blocked, without blocking it. Run it for a week or two, including a normal business cycle, then fix or allow each reported source before switching to enforcement. Free tools such as Mozilla Observatory or securityheaders.com grade your headers from the outside and show what is missing.
Where to add them
In the web server or hosting configuration, a CDN, or a security plugin. Server level is most reliable.
After every change
Re-test when you add a new plugin, widget or payment method, since the CSP may need a new source.
Our performance and security optimization sets up and tests headers along with other hardening, with prices on our pricing page. When you do not need help: on a hosted platform like Shopify many headers are set for you, and on a simple site the four low-risk headers take minutes to add yourself. Book a call if your site has payments or logins and you want CSP done carefully.
Frequently asked questions
Can security headers break my website?
HSTS and CSP can, if they are added without preparation. The other common headers rarely cause problems. Test in report-only mode first for CSP.
Do I need security headers on a simple brochure site?
Yes, at least the low-risk ones. They cost nothing and protect visitors, and search engines and procurement checklists increasingly look for them.
Does Shopify or Squarespace set headers for me?
Hosted platforms set several headers themselves and limit what you can change. Check what is already present with an online header checker.
Is X-XSS-Protection still needed?
No. Modern browsers ignore it, and a Content Security Policy is the current protection against script injection.
Want your headers set without breaking checkout?
Book 15 minutes. We check your current headers, list what is missing and tell you what it would take to add them safely.
Book a free 15-minute call