Security Headers Explained: CSP, HSTS, and X-Frame-Options

What a security header actually is

A security header is an instruction your server sends back with every page — a line in the HTTP response, invisible in the browser, that tells the visitor's browser how to behave defensively while it renders that page. It's not a WordPress feature. It's set at the web-server or hosting/CDN layer, which means it applies to every request that layer serves, regardless of what WordPress itself does or doesn't do. That also means WordPress core has no built-in way to add most of these on its own — you set them at the server config, through your host, through a CDN, or through a plugin that injects them for you.

Most WordPress sites send almost none of these by default. That's not because they're hard to add — it's because they're easy to forget, since nothing about a normal site visibly breaks when they're missing. The four below are the ones that matter most for a typical WordPress or WooCommerce site.

Content-Security-Policy (CSP) — the powerful one, and the one to test carefully

CSP tells the browser exactly which sources it's allowed to load scripts, styles, images, and other resources from. Done well, it's one of the strongest defenses against cross-site scripting: even if an attacker manages to inject a malicious script tag into your page — through a vulnerable plugin, a compromised comment field, whatever the route — a correctly configured CSP can simply refuse to run it, because it wasn't loaded from an allowed source.

That strength is also why it's the header most likely to break something if you're not careful. A strict CSP disables inline scripts and inline event handlers (<script>...</script> blocks and onclick="..." attributes) by default — and WordPress themes, page builders, and plugins use both constantly. Turn on a strict policy without testing first, and you can silently break a slider, an analytics snippet, or a checkout script, with no error message pointing at the cause. The fix isn't to give up on CSP — it's to build the allowlist gradually (checking your browser's console for blocked-resource warnings after each change) rather than copying a strict policy from a tutorial and assuming it fits your site.

Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline'

Strict-Transport-Security (HSTS) — commit carefully, it's slow to undo

HSTS tells the browser "only ever connect to this domain over HTTPS, for the next N seconds — don't even try plain HTTP, and don't let the visitor click through a certificate warning." It's a genuinely effective defense against downgrade attacks, where someone on the same network intercepts an initial HTTP request before it gets redirected to HTTPS.

The part worth knowing before you enable it: the browser caches this setting for the full max-age you specify, and there's no way to cancel that from the HTTP side of things — you can't "unset" HSTS over plain HTTP, by design. If you enable it with a long max-age and then something about your HTTPS setup breaks, visitors whose browsers already cached the policy will refuse to fall back to HTTP until either the cache expires or they revisit while your HTTPS is serving a corrected, shorter max-age. The practical takeaway: make sure HTTPS is solid and permanent on your site before turning this on, and start with a shorter max-age while you confirm everything works, rather than committing to a multi-year setting on day one.

Strict-Transport-Security: max-age=31536000; includeSubDomains

X-Frame-Options — a one-line defense against clickjacking

This one is simple and low-risk to add. It tells the browser whether your pages are allowed to be loaded inside an <iframe> on someone else's site. Without it, an attacker can build a page that invisibly overlays your site in an iframe, positions a fake button over your real "delete account" or "confirm purchase" button, and tricks a visitor into clicking something they never meant to — a technique called clickjacking. Setting it to SAMEORIGIN allows your own site to frame itself (useful if you embed your own pages anywhere) while blocking everyone else.

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options: nosniff — closes a quiet MIME-sniffing gap

Browsers sometimes try to guess a file's actual type rather than trusting what the server declared — a practice called MIME sniffing. That guessing can be exploited: a file uploaded as "plain text" that actually contains HTML/script markup could, without this header, get interpreted and executed as a document instead of being treated as inert text. Setting nosniff tells the browser to trust the declared content type and not go looking for a different interpretation. It's a single line, essentially zero risk of breaking anything, and worth adding by default.

X-Content-Type-Options: nosniff

Checking what your site actually sends today

You don't have to guess. securityheaders.com is a free, widely used tool that scans any public URL, shows exactly which of these headers are present, and grades the result — a fast way to see your starting point before changing anything, and to confirm a change actually took effect afterward.

How these actually get set on a WordPress site

None of this typically means editing WordPress core or plugin code. The three common routes: (1) your host's control panel, if it exposes header settings directly; (2) a CDN or edge provider like Cloudflare, which can add these headers to every response without touching your origin server at all; (3) your own .htaccess (Apache) or server block (nginx), if you manage server config directly or your host allows it. A security plugin can also inject some of these for you — but CSP specifically is worth configuring deliberately rather than accepting a generic default, precisely because the "right" policy depends on what scripts and embeds your specific site actually uses.

Whichever route you use, treat CSP as the one to roll out gradually and test — a broken slider is annoying, a broken checkout is a lost sale. The other three are close to zero-risk additions once you know the syntax.