How to Add Security Headers to WordPress

WordPress security is not limited to strong passwords, plugins, firewalls, and regular updates. Your web server can also send instructions to visitors’ browsers that control how website content is loaded and how certain types of potentially dangerous requests are handled.

These instructions are called HTTP security headers.

Properly configured security headers can help reduce risks associated with clickjacking, unwanted content types, insecure connections, cross-origin requests, and certain types of browser-based attacks.

This guide explains how to add security headers to WordPress, which headers are commonly used, different ways to configure them, how to test your configuration, and mistakes to avoid.

---

What Are Security Headers?

Security headers are HTTP response headers sent by a web server to a visitor’s browser.

For example:

Strict-Transport-Security: max-age=31536000

The browser reads the header and follows the instruction provided by the website.

Security headers can help establish rules for:

• HTTPS usage
• Content types
• Framing
• Referrer information
• Browser feature access
• Content loading
• Cross-origin behavior

They are not specific to WordPress, but they can provide an additional security layer for WordPress websites.

---

Why Are Security Headers Important for WordPress?

WordPress websites commonly use multiple components:

• WordPress core
• Plugins
• Themes
• JavaScript libraries
• External fonts
• CDNs
• Analytics services
• Payment services
• APIs
• Embedded content

Security headers can help control how browsers interact with these resources.

They can help reduce exposure to certain browser-based attacks, although they cannot fix vulnerable plugins, weak passwords, compromised hosting accounts, or insecure application code.

---

Common Security Headers for WordPress

Several headers are commonly considered when hardening a website.

1. Strict-Transport-Security

The Strict-Transport-Security header, commonly called HSTS, tells compatible browsers to use HTTPS for future requests to the domain for a specified period.

Example:

Strict-Transport-Security: max-age=31536000

This can help prevent certain downgrade or accidental HTTP connection scenarios.

Important Warning

Do not enable aggressive HSTS settings until you are confident that the entire website and relevant subdomains can consistently operate over HTTPS.

HSTS can make browser access more restrictive once cached.

---

2. Content-Security-Policy

The Content-Security-Policy, or CSP, header allows you to define which sources the browser may load content from.

Example:

Content-Security-Policy: default-src 'self'

CSP can help mitigate certain forms of cross-site scripting and unwanted resource loading.

However, a strict CSP can also break WordPress websites if they rely on:

• Inline scripts
• Inline styles
• External JavaScript
• Google services
• Analytics
• CDNs
• Payment providers
• Embedded content
• Plugin-generated resources

Therefore, CSP should be introduced carefully.

---

3. X-Content-Type-Options

This header helps prevent browsers from MIME-sniffing certain responses.

A commonly used configuration is:

X-Content-Type-Options: nosniff

This is generally straightforward to implement.

---

4. Referrer-Policy

The Referrer-Policy header controls how much referrer information a browser sends when navigating from your website to another location.

A commonly used setting is:

Referrer-Policy: strict-origin-when-cross-origin

This allows the browser to send useful origin information while limiting more detailed URL information during cross-origin navigation.

---

5. Permissions-Policy

The Permissions-Policy header can control access to certain browser capabilities.

For example:

Permissions-Policy: camera=(), microphone=(), geolocation=()

This configuration requests that the browser not allow those features to be used by the website.

However, do not disable browser features that your website actually requires.

For example, a website using browser-based location functionality may need different settings.

---

6. X-Frame-Options

The X-Frame-Options header can control whether a page can be displayed inside a frame.

A common configuration is:

X-Frame-Options: SAMEORIGIN

This can help reduce certain clickjacking scenarios.

However, websites that intentionally need to be embedded by other domains may require a different approach.

For modern applications, CSP’s frame-ancestors directive can provide more flexible framing control.

---

7. Cross-Origin Headers

Some websites may also use headers related to cross-origin behavior, such as:

• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy
• Cross-Origin-Embedder-Policy

These headers can provide stronger isolation in specific scenarios.

However, they should not be enabled blindly.

Plugins, embedded resources, analytics, external APIs, and third-party content can behave differently after cross-origin restrictions are introduced.

---

Before Adding Security Headers

Before modifying headers on a production website, create a backup and understand your website’s dependencies.

Make a list of:

• External scripts
• CDN resources
• Fonts
• Analytics
• Payment gateways
• Embedded videos
• Advertising networks
• APIs
• Third-party plugins

This is especially important when configuring CSP and cross-origin policies.

---

Method 1: Add Security Headers Using .htaccess

If your WordPress website runs on Apache, security headers can be configured through .htaccess.

The exact configuration depends on your hosting environment.

A basic example might look like:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

This example adds three commonly used headers.

Important

Do not blindly copy large collections of security headers from random tutorials.

Every website has different requirements.

An incorrect header configuration can break legitimate functionality.

---

Adding HSTS With .htaccess

Once HTTPS is fully configured and working correctly, an HSTS header can be added.

For example:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Before enabling HSTS, make sure:

• HTTPS works correctly.
• HTTP redirects properly to HTTPS.
• Important subdomains support HTTPS if they will be affected.
• Your SSL/TLS certificate is valid.
• You understand the long-term browser behavior.

Avoid adding includeSubDomains or HSTS preload-related directives without carefully evaluating your domain and subdomains.

---

Method 2: Add Security Headers in Nginx

If your WordPress website uses Nginx, headers can be configured in the server configuration.

For example:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;

HSTS could be configured after HTTPS is confirmed:

add_header Strict-Transport-Security "max-age=31536000" always;

The exact configuration location depends on your Nginx setup.

After changing Nginx configuration, validate the configuration before reloading the server.

---

Method 3: Add Security Headers Through a WordPress Plugin

If you do not have server-level access, a WordPress security or header-management plugin may provide an easier interface.

The general process is:

1. Install a reputable plugin.
2. Activate it.
3. Locate its security header settings.
4. Select the headers you want.
5. Configure the values.
6. Save the settings.
7. Test the website.

A plugin can be convenient for administrators who are not comfortable editing Apache or Nginx configuration.

However, avoid installing several plugins that all attempt to modify the same headers.

---

Method 4: Add Security Headers Through Cloudflare

If your website uses Cloudflare or another reverse proxy/CDN, security headers can also be configured at the edge.

This can allow headers to be added before responses reach visitors.

The exact configuration depends on the Cloudflare features and plan available to your account.

Before adding headers at the CDN level, check whether your WordPress hosting or security plugin already adds them.

Otherwise, you may create duplicate or conflicting headers.

---

Recommended Starting Configuration

For many WordPress websites, it is reasonable to start with a small set of relatively straightforward headers.

For example:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN

Then consider HSTS after HTTPS has been thoroughly tested.

CSP and advanced cross-origin policies should generally be introduced more carefully because they can have a greater effect on website functionality.

---

How to Add a Content Security Policy

CSP is one of the most powerful security headers, but it is also one of the easiest to configure incorrectly.

A simple policy might look like:

Content-Security-Policy: default-src 'self'

However, this may break many WordPress websites.

A real WordPress website may load resources from:

• Its own domain
• Google Fonts
• Google Analytics
• YouTube
• Payment providers
• CDN providers
• Social media services
• Plugin-specific domains

Therefore, a CSP should be designed around the resources your website actually uses.

---

Use CSP Report-Only Before Enforcing a Policy

For complex websites, CSP can be introduced using a report-only approach.

The header is:

Content-Security-Policy-Report-Only

Instead of immediately blocking resources, the browser can report policy violations without enforcing the policy.

This can help identify legitimate resources that need to be included before switching to an enforcing CSP.

A staged approach is often safer than immediately deploying a highly restrictive policy.

---

Security Headers for WooCommerce Websites

WooCommerce websites require additional testing because they often depend on:

• Payment gateways
• External JavaScript
• Customer accounts
• Checkout services
• Analytics
• Marketing tools
• Shipping integrations

A restrictive CSP or cross-origin policy can interfere with checkout functionality.

After changing headers, test:

• Product pages
• Cart
• Checkout
• Customer login
• Account pages
• Payment processing
• Order confirmation

Never assume that the homepage working means the entire ecommerce website is working.

---

How to Check Whether Security Headers Are Working

After configuring your headers, verify the actual HTTP response.

You can use:

• Browser developer tools
• Command-line tools
• Online HTTP header scanners
• CDN debugging tools
• Security testing services

In a browser, open Developer Tools and inspect the Network tab.

Select a page request and look under Response Headers.

You should see headers such as:

X-Content-Type-Options: nosniff

and:

Referrer-Policy: strict-origin-when-cross-origin

---

Check Headers With the Command Line

If you have command-line access, you can inspect HTTP response headers with a tool such as:

curl -I https://example.com

The response should display the headers returned by your website.

For example:

HTTP/2 200
content-type: text/html
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
x-frame-options: SAMEORIGIN

The exact response will vary depending on your hosting environment and configuration.

---

Test After Adding Headers

Do not stop testing after confirming that the headers exist.

Check the website’s actual functionality.

Test:

• Homepage
• Blog posts
• Contact forms
• Search
• Login
• Registration
• Password reset
• Media
• JavaScript features
• Embedded videos
• Analytics
• Payment processing
• WooCommerce checkout
• Third-party integrations

A security header is useful only when it improves security without unnecessarily breaking legitimate website functionality.

---

Common Security Header Problems

Problem 1: Website Design Breaks

A restrictive CSP may block CSS, fonts, or JavaScript.

Solution

Inspect the browser console for CSP violations and adjust the policy to allow legitimate resources.

---

Problem 2: JavaScript Stops Working

Some plugins rely on inline JavaScript or external resources.

Solution

Review CSP errors and identify the blocked resource.

Do not simply disable CSP without investigating the cause.

---

Problem 3: Embedded Videos Stop Working

YouTube, Vimeo, and other external services may require explicit CSP permissions.

Solution

Review the required domains and add only the necessary sources to the policy.

---

Problem 4: WooCommerce Checkout Breaks

Payment providers often load external scripts.

Solution

Review the payment provider’s required domains and test the entire checkout flow after adjusting the policy.

---

Problem 5: Duplicate Headers Appear

Headers can be added by:

• Apache
• Nginx
• WordPress plugins
• Cloudflare
• Hosting security systems

If multiple layers add the same header, the resulting behavior may not be what you expect.

Choose one primary location for each policy whenever practical.

---

Common Mistakes When Adding Security Headers

1. Copying a Security Header Configuration Without Testing

A configuration designed for one website may not work for another.

2. Deploying a Strict CSP Immediately

CSP can break legitimate resources if introduced without understanding the website’s dependencies.

3. Enabling HSTS Too Aggressively

HSTS changes browser behavior for HTTPS access.

Make sure your HTTPS configuration is reliable before enabling long-lived policies.

4. Using Deprecated Headers

Some older security headers are no longer useful in modern browsers.

Do not add headers simply because they appear in an old security tutorial.

5. Ignoring Third-Party Services

Modern WordPress websites often rely on external resources.

Security policies must account for legitimate integrations.

6. Adding Headers in Multiple Places

Avoid unnecessary duplication between WordPress, the web server, CDN, and security plugins.

7. Assuming Security Headers Fix Vulnerable Plugins

Headers are an additional defense layer.

They do not replace software updates or secure application code.

---

Security Headers and WordPress Caching

Caching can sometimes complicate header changes.

Depending on your setup, cached responses may continue serving old headers.

If you have changed headers but cannot see the new values:

1. Clear the WordPress cache.
2. Clear CDN cache.
3. Purge reverse-proxy cache if applicable.
4. Test in a private browser window.
5. Inspect the actual HTTP response.

Always test the response received by an external visitor rather than relying only on server configuration files.

---

Security Headers and HTTPS

Many security headers work alongside HTTPS.

A secure WordPress website should generally have:

• A valid SSL/TLS certificate
• HTTPS enabled
• HTTP-to-HTTPS redirection
• Correct internal HTTPS URLs
• No mixed-content warnings
• Properly configured HSTS when appropriate

Security headers cannot compensate for a broken or incorrectly configured HTTPS setup.

---

WordPress Security Headers Checklist

Use this checklist when implementing security headers:

• Create a website backup
• Confirm HTTPS works correctly
• Identify external resources
• Check existing response headers
• Decide where headers will be managed
• Add X-Content-Type-Options
• Configure Referrer-Policy
• Consider X-Frame-Options
• Evaluate HSTS
• Design CSP carefully
• Consider Permissions-Policy
• Test third-party integrations
• Test JavaScript
• Test forms
• Test login
• Test WooCommerce if applicable
• Clear caches
• Recheck response headers
• Monitor for browser errors

---

A Practical Security Header Strategy

Rather than adding every available header at once, use a gradual approach.

Stage 1: Basic Headers

Start with straightforward policies such as:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN

Stage 2: HTTPS Protection

After confirming that HTTPS works reliably, consider:

Strict-Transport-Security

Stage 3: Content Control

Develop a suitable:

Content-Security-Policy

Start in report-only mode if appropriate for your environment.

Stage 4: Advanced Isolation

Only introduce advanced cross-origin policies when you understand the application’s requirements.

This staged approach makes troubleshooting much easier.

---

Frequently Asked Questions

Do security headers protect WordPress from malware?

Security headers can provide an additional browser-level defense, but they do not directly replace malware scanning, software updates, firewalls, or secure hosting.

Can I add security headers without a plugin?

Yes. They can be configured at the web server, CDN, reverse proxy, or other infrastructure layer depending on your setup.

Which security headers should WordPress use?

There is no universal set for every website. Commonly considered headers include HSTS, CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, and Permissions-Policy.

The correct configuration depends on your website’s functionality.

Can security headers break my WordPress website?

Yes. Particularly restrictive CSP and cross-origin policies can prevent legitimate scripts, styles, frames, APIs, or external services from working.

Always test after changing them.

Should I use both a plugin and Cloudflare for security headers?

You can, but avoid unnecessary duplication. Decide which layer should be responsible for each header and verify the final response.

How do I know whether my security headers are configured correctly?

Inspect the actual HTTP response using browser developer tools, command-line tools, or reputable security testing services, and then test your website’s functionality.

---

Final Thoughts

Adding security headers to WordPress is an effective way to strengthen the browser-side security of your website. Headers such as HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, and Permissions-Policy can provide additional controls over how browsers interact with your website.

However, security headers work best as part of a broader security strategy.

Keep WordPress and its plugins updated, use strong authentication, protect administrator accounts, scan for malware, maintain reliable backups, use secure hosting, and monitor suspicious activity.

Most importantly, do not copy a complex security-header configuration without testing it. Start with simpler policies, understand your website’s dependencies, introduce stricter controls gradually, and verify the final HTTP response.

A carefully tested security-header configuration can strengthen WordPress without sacrificing the functionality your visitors and administrators rely on.