TL;DR
WordPress security headers should be audited before launch because strict rules can break scripts, ads, embeds, analytics, payment flows, and admin behavior. Start with reportable settings and tighten carefully.
- Check CSP, HSTS, X-Frame-Options or frame-ancestors, referrer policy, and permissions policy.
- Test logged-in admin, forms, checkout, embeds, analytics, and ad scripts before enforcing strict headers.
- Keep rollback access at the server or hosting layer in case a header blocks critical functionality.
TL;DR
- Audit headers at every layer: WordPress, host, CDN, and browser.
- Use CSP Report-Only before enforcement to avoid blocking valid assets.
- Confirm the final response with `curl -I` and browser devtools, not just the admin panel.
Start With a Baseline Response Check
Before you change anything, capture the current response headers from production. That baseline tells you whether headers are already present, whether a plugin is adding them, and whether a CDN is rewriting them before they reach the browser. Use a command like curl -I https://example.com and compare it with the same request on staging.
Do not stop at the homepage. Test a post, a page, a logged-out archive, and a representative asset path if your stack treats them differently. WordPress sites often have one header set on the home route and a different set on cached content or media files.
Headers That Need Review
Some headers are safe almost everywhere. Others depend on your theme, plugins, and embedded services. Audit them one by one instead of applying a blanket rule.
- Strict-Transport-Security: verify HTTPS is fully stable before enabling long max-age values.
- Content-Security-Policy: check scripts, styles, fonts, analytics, embeds, and payment widgets.
- X-Frame-Options or frame-ancestors: confirm the site does not need to be embedded anywhere legitimate.
- Referrer-Policy: make sure outbound referrals still carry the amount of data you actually want shared.
- Permissions-Policy: disable browser features you do not use, but avoid breaking camera, microphone, or geolocation features if your site needs them.
- X-Content-Type-Options: set
nosniffand confirm static assets are served with correct MIME types.
Audit CSP in Report-Only Mode First
CSP is the header most likely to break a WordPress site if you enforce it too early. Start with Content-Security-Policy-Report-Only, then collect violations while the site continues to function. That gives you a list of blocked sources without taking production down.
Content-Security-Policy-Report-Only: default-src 'self';
script-src 'self' 'unsafe-inline' https://www.googletagmanager.com;
img-src 'self' data: https:;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
report-uri /csp-reportIf the report stream shows legitimate resources, decide whether to whitelist them, move them to local assets, or remove them entirely. Once the report noise drops to a stable level, move to enforcement on staging and then production.
Check the Entire Delivery Path
WordPress rarely sends headers from only one place. Plugins, theme code, .htaccess rules, Nginx config, host control panels, CDNs, and edge caching can all inject or overwrite the final response. If a header looks correct in one place and wrong in another, assume the highest layer in the chain is winning.
This matters most when a CDN serves cached HTML. The browser only sees the cached response, not the new origin rule you just added. After every change, verify the exact route that users hit in production, not only the origin server.
Common Failure Patterns
- HSTS is enabled before the full site and all subdomains are consistently on HTTPS.
- CSP blocks inline scripts used by a page builder, analytics tag, or payment widget.
- The site sends duplicate headers from both the host and a security plugin.
- Testing happens only in the admin area, not on the front-end templates that visitors actually use.
- Cache purge is skipped, so old responses keep serving even after the config changes.
If a header change fails, the fix is usually not “turn it off.” The fix is to find the layer that injected the bad value and correct it there. That keeps the site consistent and avoids patchwork behavior across routes.
A Safe Ship Checklist
- Confirm the site uses HTTPS everywhere.
- Validate header output on homepage, post pages, archives, and assets.
- Use CSP Report-Only before switching to enforcement.
- Purge caches and test the CDN response after every change.
- Document the final approved header set for future maintenance.
The goal is not maximum header count. The goal is a stable, repeatable security posture that survives deploys, plugin updates, and cache layers without drifting.
Generate a clean header set after the audit
Use the audit results to build a smaller, verified header policy. Start with the headers you can defend, not the ones that look impressive in a checklist.
Production Use Case
Security headers are tied to a public tool and have high practical value when the post explains CSP and HSTS risk.
Use report-only testing before enforcing strict headers. A Content Security Policy or permissions rule can break analytics, embeds, payment flows, admin assets, or theme scripts when copied without reviewing browser console violations.
- Apply the examples to a staging site first, then document the exact setting or code path you changed.
- Recheck linked tools, screenshots, commands, and code snippets whenever WordPress or server behavior changes.
- Refresh the guide when the workflow changes so the page remains useful as a standalone reference.
Frequently Asked Questions
What is the safest way to test CSP on WordPress?
Start with Report-Only mode, collect violations, and only enforce the policy after the allowed resource list is stable.
Should I test headers on localhost only?
No. Local testing is useful, but the real check is staging and production because CDN and cache behavior can change the final response.
Why do security headers disappear after caching?
A cached response may be served before the new rule reaches the browser, or a CDN may override the origin header set. Purge and retest the full path.
Do all WordPress sites need the same headers?
The baseline is similar, but CSP and Permissions-Policy often need site-specific tuning for embeds, analytics, and payment or form providers.