Your WordPress site can be secure in many ways, strong passwords, good hosting, updated plugins. But there’s a layer of protection that often gets overlooked: HTTP security headers.
These are small instructions your server sends to the browser. They tell the browser how to behave when loading your site. Implemented correctly, they can prevent attacks like Cross-Site Scripting (XSS), clickjacking, and information disclosure.
The best part? They’re relatively easy to add to WordPress. This guide covers the most important headers, why they matter, and how to implement them.
When a browser requests your WordPress site, your server responds with the pageStatic content (e.g., "About Us," "Contact") not part of chr... More content plus a set of HTTP headers. Security headers tell the browser things like:
Without these headers, browsers default to less secure behavior. Adding them costs almost nothing and significantly hardens your site.
Here are the headers every WordPress site should consider, from most critical to nice-to-have.
Prevents: Clickjacking (hiding malicious links under fake UI elements)
This headerThe top section of a website, usually containing the logo, n... More stops other sites from embedding your site in an iframe. Unless you explicitly need your site embeddable (e.g., for a widgetA small block that adds specific content/functionality to wi... More), lock it down.
Recommended value:
X-Frame-Options: DENY
Prevents: MIME type sniffing (browsers guessing file types, which can turn images into executable code)
This tells the browser: “Don’t guess the file type. Use exactly what I told you.”
Recommended value:
X-Content-Type-Options: nosniff
Controls: How much referrer data (where the user came from) is sent to other sites
This balances privacy and functionality. Your own site sees full referrers; external sites only see the origin domain.
Recommended value:
Referrer-Policy: strict-origin-when-cross-origin
(Note: this is the default in modern browsers)
Enforces: HTTPS-only access
Once a user visits your site over HTTPS, HSTS tells the browser to never use HTTP again for that domain, even if the user types http://.
Recommended value:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
(2-year expiry, includes subdomains, ready for browser preload lists)
Protects: Session cookies from theft and tampering
These are attributes on the cookie headerThe top section of a website, usually containing the logo, n... More, not a separate headerThe top section of a website, usually containing the logo, n... More. They ensure cookies are only sent over HTTPS, can’t be read by JavaScriptA programming language used to create interactive elements o... More, and aren’t sent cross-site.
Recommended cookie format:
Set-Cookie: name=value; Secure; HttpOnly; SameSite=Strict
Prevents: XSS and data injection attacks, the big one
CSP is powerful but complex. It tells the browser exactly which sources are allowed to load scripts, styles, images, fonts, and more. A well-configured CSP can stop an XSS attack even if an attacker finds a vulnerability.
Basic recommended value (adjust for your site):
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; object-src 'none'
Warning: CSP is easy to break. Test thoroughly before deploying to production.
Prevents: Information disclosure to attackers
These headers announce exactly what server software and version you’re running, useful for attackers scanning for known vulnerabilities. Remove or minimize them.
Recommended: Remove entirely, or set to generic values like Server: webserver
| HeaderThe top section of a website, usually containing the logo, n... More | Action |
|---|---|
X-XSS-Protection | Set to 0 (modern browsers ignore it; in old ones, it introduces more risks than benefits) |
Public-Key-Pins | Deprecated. Do not use. |
You have several options, from plugins to manual code.
Recommended plugins:
These let you toggle headers on/off without touching code.
Add to your root .htaccess file:
<IfModule mod_headers.c>
Header set X-Frame-Options "DENY"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header unset X-Powered-By
Header unset Server
</IfModule>Add to your server block configuration:
add_header X-Frame-Options "DENY" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; add_header X-Powered-By "" always;
functions.php (PHP)For headers that can’t be set at the server level, or for conditional headers:
add_action('send_headers', 'add_security_headers');
function add_security_headers() {
header('X-Frame-Options: DENY');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');
// Do NOT set HSTS here if you have mixed HTTP/HTTPS content
}Important: HSTS should ideally be set at the server level, not in PHP, to protect all requests including static files.
After implementing, verify they’re working correctly.
observatory.mozilla.org) – Comprehensive scan with letter gradingYou should see your added headers listed.
Secure and HttpOnly flagsHTTP security headers are not a replacement for good WordPress hygiene, keeping plugins updated, using strong authentication, and choosing reliable hosting. But they are a powerful, low-effort addition that closes several common attack vectors.
Start small. Implement X-Frame-Options, X-Content-Type-Options, and Referrer-Policy first. Then add HSTS. Finally, tackle CSP gradually.
Test after every change. And remember: some headers (especially CSP) can break functionality if misconfigured. Always test on a staging site first.