How to Safely Configure HTTP Security Headers for Your WordPress Site

Learn what HTTP security headers are, which ones matter most for WordPress, and how to enable them safely without breaking your live site.

Why HTTP Security Headers Matter for WordPress

HTTP security headers are small pieces of information your server sends with each page request. Modern browsers use them to enforce extra security rules, helping protect against attacks like cross-site scripting (XSS), clickjacking, and data exposure. They don’t replace other security layers (hosting, plugins, backups), but they are an important part of hardening your WordPress site.

Because headers are applied at the server or application level, a mistake can affect your entire site. This guide focuses on a safe, practical setup that most business and marketing sites can use without breaking layouts, Elementor designs, or third?party scripts.

Core Security Headers You Should Know

There are many possible headers, but you’ll get most of the benefit from a small, well?chosen set. The following are widely recommended by security standards and browser vendors.

1. Strict-Transport-Security (HSTS)

What it does: Tells browsers to always use HTTPS for your domain, even if someone tries to load an HTTP version. This helps prevent protocol downgrade and cookie hijacking attacks.

• Only enable if your site is fully on HTTPS with a valid SSL certificate.
• Common value: max-age=31536000; includeSubDomains; preload (use preload only once you’re confident).

HSTS is part of the security header set documented in modern browser and security guidance, and is considered a best practice for HTTPS sites. Source

2. X-Frame-Options

What it does: Controls whether your pages can be embedded in an iframe on another site. This helps prevent clickjacking attacks.

• Typical values: SAMEORIGIN (allow only your own domain) or DENY (block all framing).
• Use SAMEORIGIN if you embed your own pages in iframes (rare for most business sites).

This header is still widely supported and often recommended alongside newer frame protections. Source

3. X-Content-Type-Options

What it does: Stops browsers from “MIME sniffing” files and treating them as a different type than declared. This reduces the risk of certain injection attacks.

• Common value: nosniff.
• Safe to enable on almost all WordPress sites.

Modern security guidance treats X-Content-Type-Options: nosniff as a low?risk, high?value default. Source

4. Referrer-Policy

What it does: Controls how much referrer information (the URL of the previous page) is sent when users click links to other sites.

• Helps reduce leakage of sensitive URL parameters.
• Common value: strict-origin-when-cross-origin for a good balance of analytics and privacy.

Referrer policies are part of modern privacy?oriented browser behavior and are supported by all major browsers. Source

5. Content-Security-Policy (CSP) – Advanced but Powerful

What it does: CSP lets you define exactly which sources of scripts, images, fonts, and other resources are allowed to load on your site. It is one of the strongest defenses against XSS and content injection, but also the easiest to misconfigure.

• Misconfigured CSP can break Elementor widgets, analytics, or third?party embeds.
• Start in Report-Only mode if your plugin supports it, so you can see violations before enforcing.

Because CSP is complex, OWASP recommends careful planning and incremental rollout rather than copying generic policies. Source

Where Security Headers Are Set in a Typical WordPress Stack

Depending on your hosting, headers may be controlled in several places:

• Web server config – Apache (.htaccess), Nginx, or LiteSpeed rules.
• Security or caching plugins – Many offer header toggles.
• Custom code – Using WordPress hooks like send_headers in a must?use plugin or theme.
• Reverse proxies / CDNs – Cloudflare, Sucuri, or your host’s edge firewall.

For most non?technical site owners, using a well?maintained plugin that hooks into WordPress is the safest approach. The official plugin directory includes several header?focused tools that apply headers via WordPress hooks instead of directly editing server files. Source

Safe Workflow: Configure Headers Without Breaking Your Site

Step 1 – Check Your Current Headers

Before changing anything, see what your site already sends:

1. Open your site in Chrome.
2. Right?click anywhere and choose Inspect.
3. Go to the Network tab and reload the page.
4. Click the first document request (usually your homepage URL).
5. Look under Headers ? Response Headers for entries like strict-transport-security, x-frame-options, etc.

Alternatively, you can use an online header scanner recommended by security tools and plugins to see which headers are present or missing. Source

Step 2 – Confirm You’re on HTTPS Everywhere

Before enabling HSTS or tightening other headers:

• Visit both http://yourdomain.com and https://yourdomain.com. They should both redirect to the same secure URL (usually https://www.yourdomain.com or https://yourdomain.com).
• In WordPress, go to Settings ? General and confirm both WordPress Address (URL) and Site Address (URL) use https://.
• Fix any “Not Secure” warnings or mixed?content issues before proceeding.

Step 3 – Choose a Header Management Method

For most Compass Production clients, we recommend using a dedicated header plugin rather than editing server config directly. A good plugin should:

• Expose individual toggles for each header.
• Offer safe defaults and clear warnings for risky options (especially CSP and HSTS preload).
• Apply headers using WordPress hooks so changes are easy to roll back.

If your managed hosting already sets some headers, your developer may choose to configure them at the server or CDN level instead. In that case, avoid duplicating the same header in multiple places.

Step 4 – Enable Low-Risk Headers First

Start with headers that are very unlikely to break anything:

• X-Content-Type-Options: set to nosniff.
• Referrer-Policy: set to strict-origin-when-cross-origin or a similar privacy?friendly value.
• X-Frame-Options: set to SAMEORIGIN unless you know you need framing from other domains.

Apply these, clear any caching (plugin, server, CDN), then reload your site in an incognito window and click through key pages (home, main services, contact forms, Elementor templates).

Step 5 – Carefully Enable HSTS

Once you’ve confirmed your site is fully on HTTPS and stable:

1. Enable Strict-Transport-Security with a modest max-age (for example, 1–3 months) and without preload at first.
2. Test your site again over several days. Make sure there are no HTTP?only resources or subdomains that need to stay on HTTP.
3. After you’re confident, you can increase max-age and optionally add includeSubDomains and preload if recommended by your developer or host.

Step 6 – Approach CSP Gradually (Optional)

If you want the extra protection of Content-Security-Policy:

• Start with a very simple policy that allows your own domain and known CDNs you use (for example, your analytics provider, fonts, and video embeds).
• If your plugin supports Report-Only mode, enable that first so violations are logged but not blocked.
• Work with your developer to refine the policy over time, especially on sites with many third?party scripts or complex Elementor layouts.

What You Should See After Configuring Headers

Once your headers are configured and caches are cleared:

• Your site should load normally in all major browsers (Chrome, Edge, Firefox, Safari) on desktop and mobile.
• In browser dev tools under Network ? Response Headers, you should see the new headers and values you configured.
• Online header scanners should show an improved grade and list your enabled headers.
• No new console errors should appear related to blocked scripts, frames, or fonts (if they do, review CSP or X-Frame-Options settings).

Ongoing Maintenance and Safety Tips

• Document your settings. Keep a short note of which headers are enabled and where (plugin, server, CDN). This helps if you change hosts or add new security tools.
• Test after major changes. When you add new plugins, embeds, or tracking scripts, quickly re?check your headers and console for CSP or framing issues.
• Avoid overlapping configurations. If your host or CDN adds headers automatically, coordinate with your developer so you don’t send conflicting values.
• Review annually. Browser support and best practices evolve. A yearly review of your headers alongside your general security audit is a good habit.

Configured carefully, HTTP security headers give your WordPress site an extra layer of protection with very little ongoing work. Start with the safe, foundational headers, test thoroughly, and only then consider advanced options like CSP and HSTS preload.