Security Headers Explained for Non-Developers: CSP, HSTS and Friends

Your website sends a small block of metadata with every page called HTTP response headers, and some of them are instructions that tell the visitor's browser to refuse entire categories of attack. They cost nothing, visitors never see them, and most small-business sites send none.

The reason to care is not abstract: a missing clickjacking header means your contact page can be framed inside a scam site; a missing sniffing header means an uploaded file can be reinterpreted as code. This guide covers the five headers worth setting, the safe values, and — honestly — the one that can take your site offline if you copy it carelessly. Check your own score first at Mozilla Observatory, a free scanner; then come back for the values.

What a security header actually is

When a browser requests a page, the server replies with headers — key-value metadata — followed by the page itself. Security headers are instructions in that preamble: "never let this page be framed," "never sniff the content type," "only ever speak to me over HTTPS." The browser enforces them automatically on every subsequent visit. Nothing runs on your server per-request; you set them once and they harden every page.

They are a complement to patching, not a substitute — a header will not save an end-of-life CMS. Think of them as the door frame, not the lock.

The four you can set today

These are safe for almost any business site. The "blocks" column is the attack class each one closes.

This site sends the first three — you can verify any site's headers from the command line:

curl -sI https://websitesupgrade.com | grep -i "x-\|referrer"

That command (run for this guide) returns x-content-type-options: nosniff, x-frame-options: SAMEORIGIN, and referrer-policy: strict-origin-when-cross-origin — exactly the table above. MDN's header reference documents each one's options; the OWASP Secure Headers project maintains the fuller recommended set.

One caveat on X-Frame-Options: if you deliberately embed part of your site elsewhere — a booking widget, a payment frame — SAMEORIGIN will block it. Use CSP's frame-ancestors instead, which accepts a list of allowed hosts.

HSTS: the commitment header

Strict-Transport-Security tells the browser "only ever connect to me over HTTPS, for the duration I specify." It kills protocol-downgrade and sslstrip-style attacks and makes accidental http:// links self-correcting.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Two cautions. First, HSTS is sticky: once a visitor's browser has it, it applies for the whole max-age — a year here — even if you remove the header. If your HTTPS setup is unreliable or you might move to a host without TLS, do not send it yet. Second, preload is a one-way door: submitting to the HSTS preload list bakes HTTPS-only into every major browser's code permanently, and removal takes months. Only preload a domain you are certain will always be HTTPS — including every subdomain.

CSP: the powerful one that bites back

Content-Security-Policy is an allowlist: which hosts may serve scripts, styles, fonts, images, frames on your pages. Done right it neuters most injected-script (XSS) damage — a skimmer script from an unknown host simply won't execute. It is also the only header in this guide that routinely breaks sites: one missing entry and your fonts, analytics, or payment widget silently stop loading.

The safe deployment pattern, per MDN's CSP documentation:

1. Start report-only. Content-Security-Policy-Report-Only logs what would be blocked without blocking anything. Run it a week.
2. Start permissive. default-src 'self' plus explicit entries for each third party you actually use — fonts CDN, analytics, Turnstile or reCAPTCHA if you run a protected contact form.
3. Tighten after the reports are clean. Then switch to the enforcing header.
4. Re-test after every new script. A CSP written once and forgotten is tomorrow's mystery outage.

For a brochure site the honest calculus: the four simple headers plus HSTS capture most of the protection with near-zero risk. CSP earns its complexity when you handle logins, payments, or user content — or when a scanner's F grade is embarrassing the brand.

Headers you can safely ignore

A short honorable-mentions list, mostly so you do not cargo-cult dead ones. X-XSS-Protection is deprecated — every current browser ignores it, and MDN recommends omitting it because its old behavior could introduce vulnerabilities. Public-Key-Pins (HPKP) is dead entirely, removed from browsers after it famously let misconfigurations brick sites — a cautionary tale for any header that pins state. Expect-CT faded with it. And Feature-Policy was renamed Permissions-Policy — old tutorials still show the former; as of 2026 write the latter. If a checklist tells you to add any of these, the checklist is stale, not your site.

Setting and verifying

On Apache, the four safe headers are a five-line block in .htaccess (mod_headers), and this is verbatim what this site ships:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

On nginx the same values go in add_header directives inside the server block; on Cloudflare-hosted sites a Transform Rule can set them at the edge. After deploying, verify two ways: the curl -sI command above for a spot check, and an Observatory rescan for the full picture — headers occasionally get stripped by a proxy layer you forgot about. One deployment check is not enough; re-verify after host migrations, which are exactly when config gets lost.

Browse the guides index for the rest of the maintenance stack — headers are the cheap layer, not the only layer.

— Editorial team. Facts current as of 2026; we revise guides when the ground shifts.