A WordPress site should usually send HSTS, Content-Security-Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Add them at the server, CDN, or application layer, validate every header in staging, then roll out gradually so login, checkout, analytics, and embedded assets keep working.
A security header is a small instruction sent with the HTTP response. It tells browsers how to handle framing, MIME sniffing, referrer data, transport security, and script loading.
WordPress does not configure these automatically, because every hosting stack, CDN, cache, theme, and third-party script mix is different. That is why adding them needs a plan instead of a snippet copied straight into production.
This guide covers the commonly used headers, a recommended set, Apache and Nginx examples, adding them through a WordPress plugin when server access is not available, validation steps, and rollout risk. The goal is real protection without breaking forms, media, tracking, or admin workflows.
Purpose of HTTP Security Headers in WordPress
Security headers reduce browser-side risk by setting rules before a visitor’s browser even renders the page. They do not replace patching, backups, malware cleanup, or access control. They add one more layer on top of that work.
Commonly Used HTTP Security Headers
| Security header | Purpose | Rollout note |
|---|---|---|
| Strict-Transport-Security | The HSTS header tells browsers to use HTTPS after the first trusted visit. | Enable HSTS only after every subdomain, redirect, and certificate path is verified. |
| Content-Security-Policy | The content-security-policy header limits scripts, styles, frames, images, and connections. | Start in report-only mode before enforcing a strict CSP. |
| X-Frame-Options or frame-ancestors | Blocks clickjacking by controlling who can embed the page. | Use CSP frame-ancestors where possible; keep X-Frame-Options for older browser coverage. |
| X-Content-Type-Options | Prevents MIME sniffing with nosniff. | Usually low risk when assets are served with correct MIME types. |
| Referrer-Policy | This header controls how much referrer information leaves the site. | strict-origin-when-cross-origin is a balanced default for most marketing sites. |
| Permissions-Policy | Disables browser security features the site does not need. | Review maps, video, payment, and camera use before tightening. |
Recommended WordPress Security Headers
A conservative header set starts with transport, framing, MIME, referrer, permissions, and a measured Content-Security-Policy. For the CSP specifically, run report-only mode first and read the logs to see which domains the theme, editor, analytics, fonts, payment widgets, and embeds actually need.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Do not preload HSTS until you know the site is reachable only over HTTPS across every hostname you own. Old HTTP links should redirect to HTTPS in one hop, not a chain. The HSTS rule sticks in the browser for returning visitors, so a mistake here is hard to undo quickly.
Adding HTTP Headers with Apache .htaccess
If the site runs on Apache and allows overrides, the .htaccess file can set these headers directly. Test in staging first, then promote through version control or your hosting control panel.
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';"
</IfModule>
Test with cache bypassed. If the CDN also sets the same header, pick one owner. Two layers setting the same header differently is hard to debug, because the browser just enforces whichever combination ends up strictest.
Configuring HTTP Headers with Nginx
On Nginx, add_header directives usually belong in the server block or a shared include maintained by the host. This is often cleaner than editing application files, since the web server sends the response before PHP finishes rendering the page.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; frame-ancestors 'self';" always;
After reloading, check normal pages, redirects, 404 templates, admin login, REST API responses, and cached HTML. Headers are only sent when the layer that handles the request actually includes them, so a cache rule or error page can quietly skip one.
Headers in WordPress Using a Plugin
If you cannot edit Apache, Nginx, or CDN settings, a WordPress plugin is a reasonable fallback for setting these at the application layer. Pick one that lets you review the exact values it sends, export the configuration, and disable overlapping modules.
A plugin can work fine on shared hosting, but a server or CDN-level owner is usually stronger for HSTS and cache consistency. If you do go the plugin route, document the setting, who owns it, when it changed, and what output to expect.
Check HTTP Security Headers Before Rollout
- Check the headers with curl, browser DevTools, and an external header scanner.
- Confirm the same header appears on the homepage, article pages, admin login, redirects, and error templates.
- Test forms, search, comments, checkout, maps, videos, fonts, analytics, and tag-manager events.
- Run CSP in report-only mode before enforcement, then trim unnecessary third-party sources.
- Enable HSTS only after certificate coverage, redirects, www/non-www, subdomains, and CDN behavior are all verified.
- Keep a rollback path, so a header rollout can be reversed quickly if something revenue-critical breaks.
Headers protect visitors only when they actually reach the browser. Check them from the public edge, not just the origin server, since that is what a visitor’s browser actually receives after CDN cache rules or hosting changes.
Best Practice Rollout Risks
The main risk is a strict CSP or a premature HSTS rollout. A strict CSP can block inline scripts, payment frames, font providers, marketing tags, or media embeds.
Premature HSTS can lock visitors into HTTPS before every hostname is actually ready. Both are avoidable by rolling out in stages and keeping report data for each change.
The other common risk is ownership confusion. A CDN, host, Apache include, Nginx include, cache layer, and application plugin can all try to set the same header.
Pick one owner per header, document it somewhere the team can find it, and remove the duplicates. That alone prevents most of the invisible conflicts.
Implementation Notes for Teams
HSTS is the formal transport rule behind Strict-Transport-Security. CSP deserves the most review of the group, because one blocked response can silently break a script, form, frame, font, or API call.
Treat adding and changing these headers as a change-management task, not a cosmetic tweak. It works best when one person owns each header, one person reviews the report logs, and a short rollback note explains how to undo a bad change quickly.
Headers are one layer, not a full defense. Pair them with patching, backups, least-privilege accounts, malware monitoring, and WAF rules for real coverage. If the site sits behind a cache or CDN, purge it before you check what is actually being served.
Re-check headers after theme changes, checkout changes, marketing tag changes, and hosting migrations. What the CDN sends and what the origin sends should match, or you are only testing half the picture.
For broader hardening, connect this guide to WordPress security hardening, common website security threats, and the WordPress security checklist for small businesses.
FAQ
Which security headers does a WordPress site need?
A WordPress site should usually send HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and a framing control such as frame-ancestors or X-Frame-Options.
Can I add HTTPS security headers with a plugin?
Yes, you can add HTTPS security headers with an extension when server access is unavailable, but server or CDN configuration is usually more consistent for cached pages and redirects.
Should I use X-Frame-Options or CSP frame-ancestors?
Use frame-ancestors in CSP as the modern control, and keep X-Frame-Options when you need older browser support. Avoid conflicting values.
Is HSTS safe for every website?
No. Enable HSTS only when HTTPS, redirects, certificates, subdomains, and CDN behavior are stable. Consider preload only after a separate readiness review.
Can security headers break a site?
Yes. A strict CSP can block scripts, styles, frames, or API calls. Roll out in report-only mode, validate business-critical pages, and keep rollback instructions.
To implement this cleanly: start in staging, pick one configuration owner, validate the output, then promote to production. Review the same headers again after every hosting, CDN, theme, or major plugin change.
