Go to securityheaders.com and scan your WordPress site. If you haven’t explicitly configured security headers, you’ll get a D or F rating. Most WordPress sites do — because WordPress doesn’t add any security headers by default.
Security headers are HTTP response headers that tell the browser how to handle your content. They protect against cross-site scripting (XSS), clickjacking, MIME type sniffing, and other common attacks. They cost nothing in terms of performance, take minutes to set up, and significantly improve your site’s security posture.
What are security headers?
Security headers are instructions your server sends to the visitor’s browser along with every page response. They say things like “don’t let other sites embed this page in an iframe” or “only load scripts from these specific domains.”
The most important ones for WordPress:
X-Content-Type-Options: nosniff — Prevents browsers from guessing MIME types. Without this, a browser might execute a malicious file disguised as an image.
X-Frame-Options: SAMEORIGIN — Prevents your site from being loaded inside an iframe on another site. This stops clickjacking attacks where an attacker overlays an invisible iframe of your site over a fake page.
X-XSS-Protection: 1; mode=block — Tells older browsers to enable their built-in XSS filters. Modern browsers have better protections, but this header helps visitors on older browsers.
Referrer-Policy: strict-origin-when-cross-origin — Controls how much referrer information is sent when navigating away from your site. Protects user privacy without breaking analytics.
Permissions-Policy — Restricts which browser features (camera, microphone, geolocation) your site can use. If your site doesn’t use the camera, telling the browser that prevents malicious scripts from accessing it.
Strict-Transport-Security (HSTS) — Forces HTTPS connections. Once a browser sees this header, it refuses to connect over HTTP for the specified duration.
Why should you care?
They’re free protection. Security headers add zero performance overhead — they’re a few bytes in the HTTP response. Yet they block entire categories of attacks.
Google considers them a signal. While not a direct ranking factor, sites with proper HTTPS and security headers demonstrate technical competence that aligns with Google’s E-E-A-T signals.
Most WordPress attacks target the browser. XSS, clickjacking, and MIME confusion attacks all happen on the visitor’s side. Security headers are your first line of defense because they tell the browser exactly what to allow and what to block.
Your hosting doesn’t add them. Most shared hosting providers don’t configure security headers by default. This is your responsibility as the site owner.
The quick fix
Add this to your .htaccess file (Apache) before the WordPress rewrite rules:
# Security Headers
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>For Nginx, add to your server block:
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Important: Only add the HSTS header if your site is fully on HTTPS. Once set, browsers will refuse HTTP connections for a year. If your SSL certificate lapses, visitors can’t reach your site at all.
The one-click solution
OvKit includes Security Headers under Features → Security. Toggle it on, and all recommended headers are applied via PHP — no .htaccess editing, no server config access needed. Works on Apache, Nginx, LiteSpeed, and any other server that runs PHP.
OvKit also lets you customize individual headers if you need to adjust the defaults (for example, allowing iframes from specific domains).
What happens after you fix this?
- SecurityHeaders.com grade jumps to A or A+ — verifiable improvement
- Clickjacking protection active — your site can’t be embedded in malicious iframes
- XSS filter enabled — extra protection for visitors on older browsers
- MIME sniffing blocked — uploaded files can’t be misinterpreted
- HSTS forces HTTPS — eliminates HTTP downgrade attacks
Scan your site at securityheaders.com before and after to see the difference.
FAQ
Will security headers break my WordPress site?
In almost all cases, no. The headers above are conservative defaults that work with virtually all WordPress setups. The only potential issue: X-Frame-Options: SAMEORIGIN prevents your site from being embedded in iframes on other domains. If you use an external service that embeds your pages (rare for most WordPress sites), you’ll need to adjust that header.
I use Cloudflare — should I add headers there instead?
You can add them in either place. Cloudflare’s Transform Rules let you set security headers at the CDN level, which is even better since they’re applied before traffic reaches your server. But server-level headers work fine too. Avoid setting the same header in both places, as some may duplicate.
Does Content-Security-Policy (CSP) belong in this list?
CSP is the most powerful security header but also the most complex. A wrong CSP configuration can break your site’s JavaScript, styles, and images. It’s worth implementing but requires careful testing specific to your site’s scripts and resources. The headers listed above are safe defaults; CSP requires per-site customization.
Related reads: