When improving your WordPress security, you may have arrived here after a scanner flagged your site for missing headers and started looking for a quick fix. It is tempting to copy a large configuration block into production and wait for the warnings to disappear. However, that can create new problems if the settings do not match the way your site works.
WordPress security headers control different browser behaviors, and an overly strict policy could disrupt your login, checkout, forms, embeds, scripts, or other essential assets. This guide walks you through seven commonly recommended headers, one at a time. You will learn what each header protects, when to use it, what could go wrong, and where to add it.
You will also find practical steps for testing the public response and your site’s most important journeys. As part of a broader WordPress hardening plan, these steps can help you address scanner warnings with confidence, without treating a perfect scan score as the only measure of security.
: Security headers tell browsers how to handle your site’s content, connections, framing, and referrer data. Start with a measured baseline, stage CSP and HSTS, and pair the work with a WordPress security checklist. Headers do not replace updates, backups, access controls, malware scanning, or a firewall.
What security headers protect?
HTTP response headers are instructions sent alongside a page or file. They can stop MIME-type guessing, restrict framing, limit approved resource sources, require HTTPS, or reduce the URL information sent to another site.
They protect the browser-facing part of WordPress. They do not patch a vulnerable plugin, clean malicious files, stop every server-side exploit, secure a weak administrator account, or restore a failed backup. A brochure site, WooCommerce store, and membership site may also need different policies because their scripts, payment services, frames, APIs, caches, and subdomains differ.
🧭 Note: The safest policy is not the one with the most green checks. It is the one that reduces a real browser risk without blocking a journey your visitors need.
The seven headers at a glance
| Header | What it controls | Sensible starting point or status | Main risk |
|---|---|---|---|
| X-Content-Type-Options | MIME-type interpretation | nosniff, when file types are correct | Bad content types can stop assets loading |
| X-Frame-Options | Whether a response may be framed | DENY or SAMEORIGIN, based on embeds | It can block legitimate framing |
| X-XSS-Protection | Legacy browser XSS filtering | Do not rely on it; omit or disable it | It is deprecated and may behave unexpectedly |
| Content-Security-Policy | Which resources a page may load | Begin with report-only mode | An incomplete policy can break the site |
| Strict-Transport-Security | Whether future visits use HTTPS | Add after HTTPS is stable | Long durations reduce recovery options |
| Referrer-Policy | How much URL information leaves the site | strict-origin-when-cross-origin is a practical baseline | Less detail can affect analytics |
| Permissions-Policy | Which browser features pages and frames may use | Disable only features the site does not need | Restrictive rules can break embeds |
1. X-Content-Type-Options: prevent MIME sniffing
X-Content-Type-Options: nosniff tells the browser to respect the response’s declared Content-Type instead of guessing. That reduces the chance that an uploaded or mislabelled file is interpreted as executable content. MDN and OWASP both describe nosniff as the useful value.
The practical check is simple: inspect scripts, styles, uploads, downloads, and cached files. If an asset stops loading, correct its declared type. Removing nosniff only hides the delivery problem.
2. X-Frame-Options: reduce clickjacking exposure
The X-Frame-Options security header controls whether a response can appear inside a frame, iframe, embed, or object. DENY blocks framing completely; SAMEORIGIN permits framing by the same site. The obsolete ALLOW-FROM value is not a dependable current choice.
List intentional frames before choosing DENY. A partner portal, video flow, payment service, or customer dashboard may depend on them. For modern browsers, CSP’s frame-ancestors directive is more flexible, while X-Frame-Options remains a useful compatibility fallback.
💡 Note: Test the framed page itself. A page that contains an iframe can work while the response inside that iframe is still refusing to load.
3. X-XSS-Protection: treat it as legacy
X-XSS-Protection header belongs in this list because scanners and old server configurations still mention it. It was built for legacy browser filters, is deprecated, and is not a modern WordPress XSS defense.
Do not add X-XSS-Protection: 1; mode=block just to satisfy an audit. OWASP recommends omitting the header or explicitly disabling the old filter with X-XSS-Protection: 0. Modern protection comes from secure output handling, secure application code, and a carefully tested CSP.
4. Content-Security-Policy: introduce it gradually
Content-Security-Policy, or CSP, tells the browser which sources may provide scripts, styles, images, fonts, frames, forms, and connections. It can reduce the impact of some cross-site scripting and data-injection attacks by limiting where content may come from.
CSP is also the most likely header to expose hidden WordPress dependencies. Themes and plugins may use inline scripts or call external APIs. Analytics, fonts, video, forms, CDNs, and payment providers add more sources. A policy copied from another site can break the editor, login, search, account area, or checkout.
Begin with Content-Security-Policy-Report-Only. Review violations, separate required sources from unexpected ones, and enforce the policy only after testing important journeys. upgrade-insecure-requests can help with a specific mixed-content migration, but it is not a complete CSP policy.
🧪 Note: If you cannot inventory the site’s scripts, styles, frames, forms, APIs, and payment resources, do not enforce a strict CSP yet. A shorter policy is not automatically a safer one if it omits a dependency.
5. Strict-Transport-Security: require HTTPS when ready
Strict-Transport-Security, or HSTS header, tells a browser to use HTTPS for future requests to a host after the policy has been received over a secure connection. It helps prevent fallback to an unencrypted HTTP connection; it does not replace redirects, repair a certificate, or protect vulnerable application code.
Confirm valid certificates, correct redirects, fixed mixed content, and working HTTPS on every hostname users and integrations still need. Begin with a tested max-age. Add includeSubDomains only when every relevant subdomain is ready. Consider preload last because a hostname or certificate mistake becomes harder to recover from.
6. Referrer-Policy: limit URL disclosure
Referrer-Policy header controls how much of the previous page address a browser sends when it follows a link or loads a resource. A full URL can contain private paths or query parameters.
strict-origin-when-cross-origin is a practical baseline for many sites: same-origin requests retain more detail, while cross-origin requests generally send only the origin. no-referrer provides stronger privacy but may reduce campaign attribution and troubleshooting context. Check analytics, affiliate tracking, forms, and third-party services before choosing a stricter value.
7. Permissions-Policy: limit unused browser features
Permissions-Policy controls whether a page and its embedded frames may use features such as the camera, microphone, and location. It can reduce the capabilities available to content that does not need them.
First inventory the features the site actually uses. Video calls, identity checks, maps, media embeds, payments, and outside applications can rely on browser permissions. Disable unused features deliberately, then test the affected journeys and verify the delivered header. Syntax and browser support vary, so avoid copying a long feature list without checking it.
Where should you add the headers?
The browser enforces the response it receives, not the setting screen where you entered a value. A response can pass through a web server, CDN, cache, host platform, WordPress, and plugins. Any of those layers can add, override, duplicate, or bypass a header.
Use this decision path:
- Server or CDN: Prefer this when you control Apache, NGINX, or the CDN. It can cover more response types before WordPress runs. Use syntax for the correct platform and check redirects, static files, downloads, errors, and cached pages.
- Managed host: Use the host’s documented controls when server access is unavailable. Confirm which response types are covered and how its cache changes them.
- Site-specific plugin or WordPress hook: Use this when application-level control is the only practical option. WordPress provides wp_headers and send_headers, but the Developer Reference warns that a page-cache plugin or third-party cache can serve a page before wp_headers runs. A theme’s functions.php is also easy to lose during a theme change.
- WordPress security headers plugin: This can simplify administration when server access is limited. Check maintenance, security history, report-only CSP support, duplicate-header handling, and rollback controls. A plugin manages the policy; it cannot choose a safe policy without knowing the site’s dependencies.
Do not treat wp-config.php as the normal general-purpose location for response headers. A meta tag is not a substitute when the policy must cover non-HTML files, redirects, cached responses, or the full delivery layer.
🔎 Note: If a header appears in WordPress settings but not in the public response, check the cache and CDN before changing the code again. The delivered response is the source of truth. If cache behavior is part of the problem, Airlift’s WordPress performance optimization guide is a relevant companion for reviewing that delivery layer.
A safe rollout
Make each change reversible and change one policy at a time.
- Use a backup plugin and back up the relevant server, host, CDN, cache, or plugin settings.
- Map the response path, including redirects, caches, and subdomains.
- Start with nosniff, then choose framing and referrer rules around real site behavior.
- Run CSP in report-only mode. Use a short, tested HSTS duration before considering subdomains or preload.
- Test the homepage, content, login, admin, forms, search, accounts, uploads, downloads, embeds, analytics, and checkout as applicable.
- Inspect the final response with browser Network tools, curl -I, and a header checker. Check an ordinary page, a redirect, a static asset, and a cached route.
- Remove duplicate or conflicting values and keep a rollback path. If something breaks, revert the last change, clear the relevant cache, and inspect console and network errors.
A header checker reports what it observed in a response. It does not prove that WordPress core and plugins are patched, accounts are protected, backups restore correctly, or the site is free of malware.
Security headers are one layer
Keep the broader baseline in place for a complete WordPress security strategy:
- Update WordPress, plugins, themes, and server software with a WordPress security maintenance checklist.
- Use least-privilege administrator accounts, strong authentication, and multi-factor authentication where available.
- Keep tested backups outside the live site and rehearse restoration.
- Monitor vulnerable software, suspicious logins, unexpected changes, and malware with a WordPress malware scanner plugin when appropriate.
- Use a firewall to inspect harmful requests before WordPress processes them.
If the site needs protection beyond browser behavior, MalCare can provide a complementary WordPress firewall and malware protection layer. It does not make an unsafe header configuration safe or remove the need for updates, access controls, and tested backups. If the site may already be compromised, scan and contain it first; headers cannot clean infected files or repair a vulnerable plugin.
FAQs
Are WordPress security headers enabled by default?
Some may come from the host, web server, CDN, WordPress, or a plugin, and coverage can differ by response. Inspect the public response instead of assuming a setting exists because it appears in a control panel.
Should I use a WordPress security headers plugin?
It is reasonable when server or CDN access is unavailable, especially if it supports report-only CSP, handles duplicates, and offers a rollback path. It is an administration tool, not a universal policy generator.
What should I do if a header breaks the site?
Revert the last change, clear the relevant cache, and use browser console and Network errors to identify the blocked asset or request. Fix the dependency or narrow the policy before trying again.
Are security headers enough to secure WordPress?
No. They harden browser behavior but do not replace patching, access control, backups, malware detection, cleanup, monitoring, or request filtering.
Final decision
Use nosniff when file types are correct. Choose framing and referrer rules around the site’s real behavior. Treat X-XSS-Protection as legacy, introduce CSP through report-only mode, and add HSTS only after HTTPS coverage is proven across the required hostnames.
The meaningful success test is not a perfect scanner score. It is an intended header in the public response and a site whose important journeys still work.
