Security headers tell a visitor’s browser to enforce extra protections on your behalf, preventing your site from being embedded in a malicious iframe on someone else’s page, stopping a browser from guessing at a file’s type in a way that could be exploited, and controlling what information gets shared when someone navigates away from your site. They’re well-documented, essentially zero compatibility risk, and take minutes to add.
The headers worth adding
MDN’s HTTP headers reference, the standard technical documentation most browser vendors and developers rely on, covers all of these in detail. The core set worth having on nearly any WordPress site:
X-Content-Type-Options: nosniff, stops a browser from trying to guess a file’s type differently than declared, which can otherwise be exploited to run a file as something other than what it actually is.X-Frame-Options: SAMEORIGIN, prevents your pages from being loaded inside an iframe on a different site, closing off clickjacking-style attacks where a malicious site overlays invisible elements on top of your real page.Referrer-Policy: strict-origin-when-cross-origin, controls how much information about the page someone was on gets sent along when they click a link to another site, a sensible default that avoids leaking full URLs unnecessarily.Permissions-Policy, restricts which browser features (camera, microphone, geolocation) a page is allowed to request, worth setting explicitly rather than leaving on defaults if your site doesn’t need any of them.
Method 1: a security plugin
Most WordPress security plugins can add these with a single toggle, including SecondGate’s free tier, no code editing required. This is the simplest and most reliable method for most site owners.
Method 2: add them via .htaccess (Apache)
<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"
</IfModule>Add this to your site’s root .htaccess file. It requires Apache’s mod_headers module to be enabled, standard on most hosting but worth confirming with your host if the headers don’t appear after adding this.
Method 3: add them via functions.php
add_action('send_headers', function() {
header('X-Content-Type-Options: nosniff');
header('X-Frame-Options: SAMEORIGIN');
header('Referrer-Policy: strict-origin-when-cross-origin');
});This uses WordPress’s own send_headers action hook, works regardless of whether you’re on Apache or Nginx, and survives a theme update better than editing server config files directly, since it lives in your theme or a small custom plugin rather than server configuration that could get overwritten.
A note on Content-Security-Policy specifically
CSP is a more powerful header that can meaningfully reduce XSS risk, but it’s genuinely more advanced and easy to misconfigure, a poorly written policy can silently break embedded videos, web fonts, or page-builder assets without an obvious error message pointing at the cause. The OWASP Secure Headers Project covers CSP configuration in real depth if you want to go further than the basics here. Worth adding after the simpler headers above, and worth testing thoroughly on staging before enabling on a live site, rather than guessing at a policy and hoping nothing breaks.
Verify the headers are actually being sent
SecurityHeaders.com is a free tool, enter your URL and it checks which security headers your site is actually sending and grades the result, catching cases where a header was added but isn’t actually reaching the browser (a common issue if a caching layer serves a cached response from before the header was added). Refresh a cached page or clear your cache after making this change, then re-check.
Where this fits into a broader security setup
Security headers are a low-effort, essentially risk-free addition to any WordPress site, worth having alongside the more substantial protections. For the complete picture, how to secure a WordPress site covers this alongside updates, 2FA, and the rest of what actually matters most.
