WordPress Security Headers: Add Them Without Breaking It

Most guides hand you a block of code and wish you luck. Then the block editor stops saving, the map embed goes blank, and you spend an evening commenting out lines you never really understood.

Quick Answer: WordPress security headers are HTTP response headers your server sends with every page, telling the browser what it may load and how. Add HSTS, X-Content-Type-Options, X-Frame-Options and Referrer-Policy first: they are safe on almost every site. Add Content-Security-Policy last, in report-only mode, because a strict policy is what breaks the block editor.

Last verified: September 2026, against WordPress 7.1, PHP 8.5 (PHP 8.4 still in active support), Apache mod_headers and Nginx add_header.

Our engineers work through 20 to 30 client site problems a day, and "it broke right after I pasted a security snippet" is one we see most weeks. So this is the order we apply these headers ourselves, with the settings that cause trouble flagged before you paste them rather than after.

What Security Headers Actually Do (In Plain English)

Security headers are instructions, not filters. Your web server attaches them to every HTTP response, and the visitor's browser enforces them locally. No PHP runs, nothing gets scanned, and the cost to page load time is effectively zero milliseconds. That is why an external scanner can grade your site's headers in under 10 seconds without ever touching your hosting account.

Three attacks make up most of what they prevent. Clickjacking, where your login page is loaded inside an invisible frame on someone else's site. Cross-site scripting, where injected JavaScript runs with your visitor's session. And protocol downgrade, where somebody who types your domain without https gets served an unencrypted copy on café Wi-Fi.

What they do not do is equally important. A header is not a firewall and not a malware scanner. It will not stop a vulnerable plugin from being exploited on the server, and it will not clean an infection you already have. If you landed here because Google flagged the site, start with This Site May Be Hacked Google Warning: How to Remove It. Headers are hardening for a clean site, not a cure for a dirty one.

One prerequisite before you touch anything: a valid SSL certificate, with HTTPS working everywhere. Half of these headers assume it, and HSTS actively punishes a site that cannot serve it. Take a copy of the file you are about to edit, too. Restoring a broken config over SFTP at 11pm is a rough way to learn this lesson.

The Seven Headers Worth Setting in 2026 (And Two to Skip)

Seven headers carry almost all of the value, and the first four take about 2 minutes to add with no realistic risk to a normal site. Content-Security-Policy is the only one that needs testing before you enforce it. Two headers that appear in nearly every older tutorial should now be removed rather than set, because browsers dropped the features behind them.

| Header | What it prevents | Safe starting value for WordPress | What it can break | |---|---|---|---| | Strict-Transport-Security | Downgrade attacks and cookie theft over plain http | max-age=31536000 (12 months, no preload yet) | Subdomains and staging sites, if you add includeSubDomains too early | | X-Content-Type-Options | MIME sniffing of uploaded files | nosniff | Almost nothing | | X-Frame-Options | Clickjacking of your login and admin pages | SAMEORIGIN | Site editor previews and page builders, if set to DENY | | Referrer-Policy | Leaking full URLs to third parties | strict-origin-when-cross-origin | Referral attribution in some analytics tools | | Permissions-Policy | Silent access to camera, microphone, location | camera=(), microphone=(), geolocation=() | Video calls, maps and store locators that need those APIs | | Content-Security-Policy | Injected scripts and stray third-party assets | Report-only first, always | Block editor, media uploads, embeds, tag manager scripts | | Cross-Origin-Opener-Policy | Cross-window attacks through popups | same-origin-allow-popups | OAuth and payment popups, if set to plain same-origin |

The two to remove: X-XSS-Protection and Expect-CT. Chrome deleted the XSS auditor that the first one controlled, Firefox never shipped it, and the filter itself introduced side-channel bugs, which is why the OWASP Secure Headers Project now advises sending 0 or nothing. Expect-CT is obsolete, and public key pinning (HPKP) is dead: setting it can lock visitors out of your own domain for months.

Do I actually need a Content Security Policy on a small WordPress site?

Honestly, not on day one. A brochure site with five plugins gets most of its protection from the four cheap headers above, plus current PHP and current plugins. A Content Security Policy WordPress can live with takes genuine testing time, and it earns that time when you run checkout, member logins, or a stack of third-party marketing tags. Set the easy four this week. Treat CSP as its own project.

Pro Tip: Set Permissions-Policy before you install anything that asks for location or camera access. Opening one API deliberately is a two-minute job. Explaining to a client why their store locator died three weeks after launch is not.

How to Add WordPress Security Headers in .htaccess or Nginx

There are three places to set WordPress security headers: your server config, the site's .htaccess file, or a plugin. Server config is fastest, because the headers go out before PHP loads. A plugin is often the only route on locked-down shared hosting. Whichever you choose, set each header in exactly one place, because duplicates across two layers cause more breakage than strict values do.

Apache or LiteSpeed (.htaccess)

apacheCopy
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000"
  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=()"
</IfModule>

Put the security headers .htaccess block above the # BEGIN WordPress marker, never between the markers. Core rewrites everything inside them whenever permalinks are saved, so a block that lives there will quietly disappear one day and nobody will connect the two events. The always keyword matters as well: without it, Apache skips the header on error responses, so your 404 and 500 pages ship unprotected. The full behaviour is documented in the Apache mod_headers documentation, and the module is enabled by default on nearly every cPanel and Plesk control panel build.

Nginx

nginxCopy
add_header Strict-Transport-Security "max-age=31536000" 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;

Nginx has a trap that catches experienced admins. As the Nginx add_header directive reference explains, these directives are inherited only if the child level defines none of its own. Add a single header inside a location block and every header from the server block vanishes for that location. Keep the set together at server level, or repeat the whole set wherever you override it.

Plugins, caching and the edge

A plugin is a perfectly reasonable choice. The most popular header plugin in the directory passed 50,000 active installs, and a UI with an off switch is worth a lot when you cannot reach the filesystem. The trade-off is real though: plugin headers are produced by PHP, so a full-page cache or a CDN serving a stored copy can bypass them. If you run Cloudflare or any other edge in front of the site, pick one layer, either the edge or the origin, and set them there.

Insider Insight: When a site sends the same header twice with conflicting values, browsers do not merge them, and different browsers resolve the conflict differently. The symptom looks like madness: fine in Chrome, blocked in Safari. Before you add anything, run curl -sI https://yourdomain.com and read what the server already sends.

◆ Professional help available

Still seeing the WordPress problem?

Share the error, affected page, and the checks you completed. Your WordPress site can stay with its current hosting provider.

Request WordPress help→Explore WordPress support↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

Which Headers Break WordPress, and Why

Four settings cause nearly every broken site after a headers change: a strict Content-Security-Policy, X-Frame-Options set to DENY, HSTS with includeSubDomains, and a Permissions-Policy that closes an API the site actually uses. Since WordPress 7.1 arrived in August 2026, CSP is comfortably the riskiest of the four, because the editor now compiles WebAssembly inside the browser.

Content-Security-Policy and the block editor

The block editor has never been friendly to strict policies. It uses the JavaScript Function constructor internally, so a policy without 'unsafe-eval' throws an EvalError and the editor fails to load. It builds workers from blob URLs, so it needs worker-src 'self' blob:. WordPress 7.1 then added client-side media processing, which resizes and converts your uploads in the browser using a WebAssembly build of vips, as the core team's write-up describes. Per MDN's script-src reference, WebAssembly is blocked outright unless 'wasm-unsafe-eval' is present in script-src. So a policy copied from a 2023 tutorial now breaks image uploads on a fully updated site, and the visible symptom is a spinner that never finishes.

Core also sends its own Document-Isolation-Policy header on editor screens for that feature, which means piling your own Cross-Origin-Embedder-Policy on top of wp-admin is a fight you will lose.

Pro Tip: Scope the policy. Apply your strict CSP to the front end only, and either skip wp-admin entirely or give it a deliberately loose policy. Front-end XSS is the threat you are defending against anyway, and the admin area is already behind authentication.

X-Frame-Options, HSTS and the settings you cannot undo

DENY blocks your own frames as well as everyone else's. The site editor, the customizer preview and most page builders load your front end inside a frame on your own origin, so the X-Frame-Options WordPress sites want is SAMEORIGIN, not DENY. If the editor preview goes white after a headers change, that value is the first thing to check, ahead of There Has Been a Critical Error on This Website: Quick Fix.

HSTS is the one you cannot walk back quickly. The HSTS header WordPress sites can safely start with is a plain 12-month max-age and nothing else. Add includeSubDomains and every subdomain, staging boxes and legacy tools included, must serve valid HTTPS from that second onward. Add preload and you are asking browser vendors to hard-code your domain into their shipped binaries, where removal takes months. Worth knowing: this rule lives in the visitor's browser, not in DNS, so moving hosts or changing nameservers does not clear it.

Across the 4,000+ sites Hostaccent has migrated since 2016, HSTS is the setting that most often turns a routine move into a panic, because the certificate on the old server expires while browsers still refuse to load plain http. If you are planning a move, read Migrate WordPress to a New Host Without Downtime (2026) first and get the certificate live on the destination before you switch. Two related failures worth recognising: upgrade-insecure-requests can mask a genuine Mixed Content Warning After SSL instead of fixing it, and HSTS layered onto a redirect rule that was already wrong produces Too Many Redirects.

Test Everything, Then Roll Back Fast If It Breaks

Test after each header, not after all seven. We call it the three-screen check: load the front page, open a post in the block editor and upload an image, then load one page carrying an embed or a form. If all three survive, add the next header. The loop takes under 60 seconds per header and it turns a mystery outage into a known, single-line cause.

The browser console is the real diagnostic tool here, not a scanner grade. A CSP violation names the exact directive that blocked the exact resource, which is usually enough to fix it in one edit. Before enforcing anything, send Content-Security-Policy-Report-Only instead: the browser reports violations to the console and blocks nothing, so you can watch a week of real traffic and real editor sessions before you commit. Scanners like the MDN HTTP Observatory are useful for the summary, but they only see logged-out front-end pages, which is exactly where CSP problems hide.

Hostaccent's engineers close 20 to 30 client site issues every day, and in our experience a header problem is almost never solved by debugging the live policy. It is solved by restoring the previous file and reapplying one line at a time. So our team keeps a copy of the original as .htaccess.bak before editing, and confirms File Manager or SSH access works first. If a header locks you out of the dashboard, knowing your WordPress Login URL and having filesystem access is what turns a disaster into five minutes of work.

Your Next Step: A Server Where the Headers Are Already Yours

You have the order now: the cheap WordPress security headers first, Content-Security-Policy last and in report-only until your editor proves it survives. You can wire that into .htaccess yourself this weekend, or start somewhere the server config is already yours to change. Hostaccent's Basic VPS at $7.99/mo hands you full root access to your Apache and Nginx config, free 30 Gbps DDoS filtering, a 99.99% uptime guarantee and 30 days to change your mind, backed by a UK-registered company that has been hosting since 2016. Prefer not to touch server files at all? Managed WordPress hosting is the better fit. One honest caveat: no VPS plan here includes a cPanel licence, so budget for that separately if you want one.

Frequently Asked Questions About WordPress Security Headers

Do WordPress security headers affect SEO or page speed?

Not directly, and the speed cost is effectively zero, since a few hundred bytes ride along with a response your server was already sending. There is no ranking boost either, whatever a scanner grade implies. The real SEO risk runs the other way: a Content-Security-Policy that blocks your own scripts can break rendering for Googlebot, and a careless HSTS rollout can take a site offline for days. Safe beats graded.

Should I use a plugin or edit .htaccess to add security headers?

Edit the server config or .htaccess when you have access, because those headers are sent before PHP loads and they still apply when a full-page cache serves the request. Choose a plugin when your host blocks file access, when you want a fast off switch, or while you are testing a policy. What you should never do is both. Two layers sending the same header with different values produces behaviour that looks random across browsers.

Why did my block editor stop working after I added a Content Security Policy?

Almost certainly because script-src is too strict for wp-admin. The editor uses the JavaScript Function constructor, so it needs 'unsafe-eval'. It creates workers from blob URLs, so it needs worker-src 'self' blob:. Since WordPress 7.1 it also compiles WebAssembly for in-browser image processing, which needs 'wasm-unsafe-eval' or uploads hang. The clean fix is scoping: enforce the strict policy on the front end and leave the admin area looser.

Is HSTS preload safe for a WordPress site?

Only if you are confident every current and future subdomain will serve valid HTTPS for years. Preload writes your domain into browsers themselves, and removal takes months to reach everybody, so one forgotten http-only staging box or mail tool becomes unreachable for real visitors. Start with a 12-month max-age on the main domain, run it for a few weeks, add includeSubDomains once staging is clean, and only then consider preload.

Do I still need X-XSS-Protection in 2026?

No. Remove it. Chrome dropped the XSS auditor that this header controlled, Firefox never implemented it, and on the browsers that did support it the filter introduced its own vulnerabilities. Current OWASP guidance is to send 0 or omit the header entirely, and a well-scoped Content-Security-Policy is the genuine replacement. If a tutorial still recommends 1; mode=block, it has not been updated in roughly five years and its other advice deserves the same suspicion.

How do I check which security headers my site is sending?

Run curl -sI https://yourdomain.com from a terminal for the unfiltered truth, or open DevTools, select the Network tab, click the document request and read Response Headers. Free scanners such as the MDN HTTP Observatory grade the same information and flag what is missing. Check a logged-out front-end URL and a wp-admin URL separately, because caching layers and plugins frequently make those two responses look nothing alike.