WordPress security headers are instructions delivered with each HTTP response. They tell the browser how to handle HTTPS, page framing, content types, referrer information, scripts, styles, and sensitive browser features. Properly configured headers reduce the impact of several common web attacks without changing the visible design.
Headers are not a substitute for updates or malware protection, and copying an aggressive configuration can break checkout, analytics, fonts, embeds, or the WordPress editor. This guide explains the important headers, where to set them, and how to test them safely.
Book a free, no-obligation strategy call and we'll map out your next move.
How security headers protect WordPress
When a browser requests a page, the server returns content plus response headers. Security headers establish rules before or while the browser renders that content. They can require encrypted connections, prevent another site from placing a page inside a deceptive frame, stop content-type guessing, and restrict which sources may run scripts.
A header only helps when it appears on the relevant responses with a correct value. Adding it to the homepage but not login pages, errors, redirects, media, or cached responses can leave gaps. Check representative URLs rather than relying on one test.
Security headers should be one item within the broader WordPress Security Audit Checklist, alongside updates, account access, backups, permissions, and monitoring.
The most useful WordPress security headers
Strict-Transport-Security, commonly called HSTS, tells supporting browsers to use HTTPS for the site during a defined period. It should only be enabled after HTTPS works reliably for every hostname that the policy will cover. Start with a cautious duration and avoid including subdomains or requesting preload until the consequences are understood.
Content-Security-Policy, or CSP, controls where scripts, styles, images, fonts, frames, and other resources may load from. It is one of the strongest browser-side controls, but also the easiest to misconfigure on a plugin-heavy WordPress site. Build a policy from observed requirements, use report-only mode first, and remove unsafe allowances gradually.
X-Content-Type-Options with the value nosniff tells browsers not to reinterpret a declared resource type. Referrer-Policy controls how much address information is sent when a visitor follows a link. Permissions-Policy limits access to selected browser features such as camera, microphone, and geolocation when the site does not need them.
To reduce clickjacking, use the CSP frame-ancestors directive where supported, with X-Frame-Options as a compatibility layer when appropriate. Decide whether any legitimate service must embed the site before blocking all framing.
Where should the headers be configured?
- At the CDN or edge layer when it controls all public responses and changes are managed carefully.
- In the web-server configuration when the team has reliable deployment and rollback access.
- At the hosting control panel when the host provides a tested header interface.
- In WordPress only when server or edge configuration is unavailable and the plugin can cover the required responses.
Avoid defining the same header in several layers. Duplicate or conflicting policies make troubleshooting difficult, and some headers do not combine in an intuitive way. Document one source of truth, the owner, the reason for each value, and the rollback procedure.
Correct WordPress file permissions help protect configuration files, but they solve a different problem from browser response headers.
Build a Content Security Policy safely
Start by inventorying first-party and third-party resources: the theme, page builder, analytics, tag manager, payment gateway, maps, video embeds, fonts, chat, and consent platform. Test authenticated administration pages as well as the public website because the editor may load different assets.
Deploy CSP in report-only mode so violations can be collected without blocking resources. Remove noise, confirm which sources are genuinely required, and test business-critical flows. Move to enforcement only after the policy behaves correctly. Nonces or hashes can provide stronger script control than broad source allowances when the implementation supports them.