HTTP security headers are easy to copy from a checklist and surprisingly easy to misconfigure. A strict Content Security Policy can block a payment widget. HSTS can lock a broken HTTPS setup into browsers. Permissions Policy can disable a feature an embedded service genuinely needs.
The right approach is not “add every header at the strongest value.” It is to understand what each control does, test it against the real WordPress stack and deploy it in a way that reduces risk without breaking the site.
Content Security Policy controls where the browser may load resources
Content Security Policy (CSP) lets a site define approved sources for scripts, styles, images, frames and other resources. A well-designed policy can reduce the impact of cross-site scripting and unwanted third-party execution.
OWASP recommends delivering CSP as an HTTP response header and supports using Content-Security-Policy-Report-Only while developing a policy. The OWASP CSP Cheat Sheet is a strong starting point.
Why CSP is difficult on WordPress
WordPress sites often load resources from themes, plugins, analytics tools, consent platforms, video embeds, fonts and marketing services. Inline scripts and styles are also common. A policy copied from another website may therefore block legitimate functionality.
Start by inventorying what the site actually loads. Use report-only mode, review violations and gradually narrow allowed sources. Do not solve every violation by adding broad wildcards; that can remove much of the protection you were trying to create.
HSTS tells browsers to use HTTPS
Strict-Transport-Security instructs supporting browsers to use HTTPS for future requests to the host. MDN’s HSTS reference explains the header and its directives.
HSTS should be added only after HTTPS works consistently across the scope you plan to cover. The includeSubDomains directive affects subdomains; preload carries additional operational commitment. Do not add those values casually to a WordPress site with forgotten development or mail-related subdomains.
Permissions Policy limits access to browser features
Permissions-Policy can control features such as geolocation, camera and microphone for the page and embedded frames. If your site does not need them, restricting them can reduce unnecessary capability.
MDN’s Permissions Policy documentation describes the syntax and feature controls. OWASP also recommends disabling unneeded browser capabilities.
Do not forget X-Content-Type-Options
X-Content-Type-Options: nosniff tells browsers not to guess a different MIME type from the declared Content-Type. It is a simple, widely applicable control and part of the OWASP HTTP security headers guidance.
Frame protection depends on what you embed
Clickjacking protection can be implemented through CSP’s frame-ancestors directive, with X-Frame-Options retained where appropriate for older compatibility. Before blocking all framing, check whether legitimate partners, dashboards or payment flows embed your pages.
Headers belong at the right layer
Security headers may be set by the origin server, hosting panel, CDN, reverse proxy or WordPress code. Prefer the layer that consistently covers the intended responses and is easiest to audit. Adding the same header in multiple places with conflicting values creates confusion.
For sites with a complex plugin or caching stack, our WordPress fixes service isolates the active delivery layer before changing production behavior.
Test pages that use third-party services
Do not validate only the homepage. Test representative pages with:
- forms and reCAPTCHA;
- analytics and consent scripts;
- payment or booking widgets;
- embedded video;
- maps;
- CDN-hosted fonts and images;
- admin-facing functionality if headers apply there too.
Browser DevTools can reveal blocked resources, but complete the test by performing the real user action. A page that looks correct while its form submission script is blocked is not a successful rollout.
Security headers are one layer, not a WordPress security plan
Headers do not replace updates, strong authentication, least privilege, backups, server hardening or secure plugin development. Our WordPress security basics guide covers those broader controls.
A safer rollout sequence
- inventory current headers and third-party resources;
- fix HTTPS and mixed-content problems first;
- add straightforward headers such as
nosniffwhere appropriate; - develop CSP in report-only mode;
- test interactive and embedded features;
- enforce the validated CSP;
- introduce HSTS only when HTTPS scope is ready;
- monitor after deployment and after major plugin changes.
The strongest header configuration is not the one with the most directives. It is the one that is intentional, tested, documented and still protects the site after the next WordPress update.