Security Headers for WordPress: Which Ones Matter

An SSL certificate encrypts the connection between your website and your visitors. It does not tell a browser what your pages are allowed to do once they load. That second job belongs to security headers, and most websites are missing at least half of them.

They cost nothing to add, they are invisible to visitors, and they do not slow anything down. This is what they are, which ones actually earn their place in 2026, and which piece of common advice you should ignore.

What a security header actually is

Every time someone opens your website, your server sends the page along with a short set of instructions about it. Most of those instructions are housekeeping, like what character set to use. A handful of them are rules: do not let anyone else put this page inside a frame, do not run scripts from anywhere except these places, never speak to this website unencrypted again.

Browsers obey them. That is the useful part. You are not asking an attacker to behave, you are telling the visitor’s own browser what to refuse, which is a much harder thing to talk your way around.

Check what your website sends right now

Before reading about any of them, it is worth seeing where you stand. This reads the headers your website sends back and scores them out of 100.

The ones that carry the weight

Content-Security-Policy is the big one, and it is worth a quarter of the score on its own. It controls where scripts, styles, images and frames are allowed to load from, so an injected script has nowhere to send data to and nothing to load. It is also the one most likely to break your website if you rush it, which is why it belongs in a run-in period rather than a quick edit.

Strict-Transport-Security, usually called HSTS, tells browsers never to use plain HTTP for your domain again. It closes the gap on that very first request, before a redirect has had a chance to happen, which is the moment someone on the same wifi could intercept it. One year is the standard setting:

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

Clickjacking protection stops another website loading yours inside an invisible frame and collecting clicks meant for something else. Older websites do this with X-Frame-Options: SAMEORIGIN, which still works. The current way is frame-ancestors inside your Content Security Policy, which can also allow specific partners rather than being all or nothing.

X-Content-Type-Options: nosniff stops a browser guessing that an uploaded file is really something else and running it. On a website that accepts uploads, which is most of them, that guess is the whole attack.

Referrer-Policy controls how much of your address is passed on when someone clicks a link out. Full URLs can carry password reset tokens, search terms and customer references, and without this they get handed to every third party you load. strict-origin-when-cross-origin is the sensible middle ground. no-referrer is more private and perfectly valid, but you lose referrer data in your own analytics, so it is a trade rather than an upgrade.

Permissions-Policy decides which browser features anything on the page may ask for. Turning off the ones you do not use means a compromised third-party script cannot prompt your visitors for their camera or location.

Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy are the small ones, a few points each. The first cuts the link a page you opened keeps back to yours. The second stops other websites pulling your responses into their pages, though it is worth checking your own CDN and subdomains first, because a blanket setting can stop them too.

The advice to ignore

Three things turn up constantly in older guides, including an earlier version of this one, and all three are wrong now.

X-XSS-Protection should be removed, not added. It switched on a filter built into browsers. No browser has run that filter for years, so it does nothing at all today, and while it was live it had a history of being turned against the websites using it. It is dead weight that still shows up as a finding in security audits. Content Security Policy is what replaced it.

Permissions-Policy has a specific format, and the common one is silently ignored. Written as geolocation 'self', with a space and quotes, browsers cannot parse it and skip the line without complaint, so it looks configured and does nothing. It needs to be geolocation=(self), or geolocation=() to switch the feature off entirely.

A Content Security Policy of default-src 'self' and nothing else is not a starting point for WordPress. It reads well in an article and it breaks fonts, embedded maps, analytics and payment widgets the moment it goes live, usually without any visible error. A real policy names the origins your website genuinely uses, and it gets there by running in Report-Only mode first.

And the one nobody mentions

The most common real finding on a WordPress website is not a missing header at all. It is the ones the server volunteers without being asked:

X-Powered-By: PHP/8.1.2
Server: Apache/2.4.41 (Ubuntu)

By itself that is not a hole in anything. What it does is put you on a list. When a flaw is published in a particular PHP or web server version, people scan the internet for anything advertising that version, and there is no reason to be findable that way. Switching it off is a one line change on the server and it costs you nothing.

What about HSTS preload, and COEP?

Both come up in checklists and neither belongs on a normal business website.

Adding preload to HSTS writes your domain into a list compiled into browsers themselves. Getting out of it is slow, because it only clears as people update their browsers, and every subdomain has to stay on HTTPS permanently. It is a deliberate one-way decision, not a box to tick on the way to a better score.

Cross-Origin-Embedder-Policy is stricter still. Set to require-corp it blocks every cross-origin resource that does not explicitly opt in, which on a typical WordPress website means fonts, embeds, maps and ad tags stop loading. It exists for a specific technical need most websites do not have.

Where these get set

Not in WordPress. There is no screen in your dashboard for any of this. Headers come from the web server, or from a CDN such as Cloudflare sitting in front of it, which is why this usually ends as a request to whoever looks after your hosting rather than something you change yourself.

The values above are the whole job. Run the check at the top of this page, take the list of what is missing, and send it to whoever looks after your hosting along with the value each one needs. Start with the four low risk ones, leave HSTS until you are sure HTTPS works on every subdomain, and keep Content Security Policy for last.

The part that comes before all of this

Headers are worth having, and they are not the foundation. A website on a well-run server, kept up to date, with backups that have actually been restored at least once, is in better shape than one with a perfect header score and a two year old PHP version underneath it.

That is the part we take on for the websites we look after, headers included. You can read what that covers on our managed WordPress hosting and maintenance page, or get in touch if you would rather just ask someone.