How to Configure WordPress Security Headers 2026

How to Configure WordPress Security Headers is an important topic for WordPress website owners, developers, and beginners who want to improve website security. HTTP security headers allow a website to send security instructions to a visitor’s browser. These instructions can help reduce risks such as clickjacking, MIME-type confusion, information disclosure, and some types of cross-site scripting attacks. OWASP describes security headers as a useful way to add browser-level security protections.

When you learn How to Configure WordPress Security Headers, you are not installing another WordPress plugin or changing the website design. Instead, you are configuring the HTTP responses that your WordPress website sends to browsers.

For example, a server can send:

X-Content-Type-Options: nosniff

The browser can then use this instruction to avoid MIME-type sniffing.

Other headers can help with:

• Enforcing HTTPS
• Controlling which resources can load
• Preventing unwanted iframe embedding
• Controlling referrer information
• Restricting browser features
• Reducing information disclosure
• Improving the security of sensitive pages

This guide explains How to Configure WordPress Security Headers in simple language and covers several practical methods for WordPress websites.

What Are WordPress Security Headers?

Before understanding How to Configure WordPress Security Headers, let’s understand what a security header is.

An HTTP response contains information that a server sends back to a browser.

A simplified response looks like this:

HTTP/2 200
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: ...
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

These headers provide instructions to the browser.

For example:

X-Content-Type-Options: nosniff

tells browsers not to guess the MIME type of a resource. OWASP recommends this header with the nosniff value.

Therefore, How to Configure WordPress Security Headers is essentially about adding appropriate HTTP response headers to your WordPress website.

Why Should You Configure WordPress Security Headers?

Learning How to Configure WordPress Security Headers is useful because browsers can enforce additional security rules based on these headers.

Security headers can help protect against or reduce the impact of certain attacks, including:

• Clickjacking
• MIME-type confusion
• Some XSS scenarios
• Mixed-content problems
• Unwanted browser feature access
• Excessive referrer information
• Some cross-origin attacks

However, security headers are not a complete WordPress security solution.

You should still use:

• Strong authentication
• Secure passwords
• Multi-factor authentication
• Regular WordPress updates
• Updated plugins and themes
• Secure hosting
• Backups
• Malware monitoring
• Access controls

For a broader security approach, you can also read about Livasys cybersecurity services, which covers areas such as vulnerability management, security monitoring, and data protection.

This is an important point when learning How to Configure WordPress Security Headers: headers are an additional security layer, not a replacement for other security controls.

How to Configure WordPress Security Headers: Important Headers

Before changing your website configuration, you should understand the most common headers.

1. Strict-Transport-Security

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

Example:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS can help protect users from certain downgrade and man-in-the-middle scenarios by instructing browsers to use HTTPS.

Be careful with HSTS. If you configure a long duration or includeSubDomains before confirming that all relevant subdomains support HTTPS, you can cause legitimate access problems. OWASP specifically warns about this deployment consideration.

2. Content-Security-Policy

Content-Security-Policy, or CSP, is one of the most powerful but complex security headers.

A CSP controls which sources a browser is allowed to load for resources such as:

• JavaScript
• CSS
• Images
• Fonts
• Frames
• Media

A simplified example is:

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

This tells the browser to use the website’s own origin as the default source.

CSP can help mitigate certain XSS and data-injection attacks. OWASP recommends delivering CSP through the HTTP response header and notes that CSP is complex to configure and maintain.

For WordPress, you should not blindly copy a strict CSP from another website because themes, plugins, analytics tools, fonts, payment gateways, CDNs, and other services may require different sources.

3. X-Content-Type-Options

This header helps prevent MIME-type sniffing.

Use:

X-Content-Type-Options: nosniff

This is one of the simplest headers to configure.

OWASP recommends X-Content-Type-Options: nosniff and explains that it helps prevent browsers from interpreting resources as a different MIME type than the server declares.

For beginners learning How to Configure WordPress Security Headers, this is a good header to understand first.

4. X-Frame-Options

X-Frame-Options controls whether a page can be displayed inside a frame.

For example:

X-Frame-Options: DENY

can prevent the page from being framed.

This can help defend against clickjacking.

OWASP recommends using CSP’s frame-ancestors directive when possible, while X-Frame-Options remains useful for compatibility with browsers that support it.

For a website that does not need to be embedded in an iframe, you might use:

X-Frame-Options: DENY

However, if your website legitimately needs iframe embedding, do not blindly use DENY.

5. Referrer-Policy

Referrer-Policy controls how much referrer information browsers send with requests.

A commonly recommended value is:

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

OWASP recommends this value as a practical default for controlling referrer information.

This can reduce unnecessary exposure of URL details when users navigate between different origins.

6. Permissions-Policy

Permissions-Policy allows you to control access to browser features.

For example:

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

This tells the browser that these features should not be available to the website.

OWASP explains that Permissions-Policy can control browser features such as camera, microphone, and geolocation.

When learning How to Configure WordPress Security Headers, remember that the exact policy should match the features your website actually needs.

7. Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy, or COOP, controls whether a top-level document shares a browsing context group with cross-origin documents.

A common restrictive example is:

Cross-Origin-Opener-Policy: same-origin

OWASP notes that COOP can help isolate a document from cross-origin browsing contexts and is particularly relevant to browser-based applications.

This is more advanced than the basic headers and should be tested carefully on WordPress websites that use third-party integrations.

How to Configure WordPress Security Headers Using .htaccess

One of the most common ways to configure headers on Apache-hosted WordPress websites is through the .htaccess file.

Before editing .htaccess:

1. Create a backup.
2. Confirm your hosting environment uses Apache or compatible configuration.
3. Make one change at a time.
4. Test the website after each change.
5. Keep a copy of the original configuration.

A basic example is:

<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>

OWASP provides Apache examples for configuring security headers and recommends using always when appropriate so headers are included across responses.

For a website that should never be framed by another site, you could use:

Header always set X-Frame-Options "DENY"

But first verify that your website, plugins, payment tools, and embedded content do not require framing.

How to Configure WordPress Security Headers in Nginx

If your WordPress website uses Nginx, .htaccess is generally not the correct place to configure server-level response headers.

Instead, headers can be configured in the Nginx 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;

OWASP provides Nginx examples for adding HTTP response headers and notes the importance of the always option for sending headers on relevant responses.

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

A typical workflow is:

Edit Nginx Configuration
        ↓
Test Configuration
        ↓
Reload Nginx
        ↓
Open Website
        ↓
Check Response Headers

This is a safer approach to How to Configure WordPress Security Headers than making multiple configuration changes at once.

How to Configure WordPress Security Headers Using PHP

If you have access to PHP and understand the application’s request lifecycle, PHP can also send headers.

For example:

<?php

header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');
header('X-Frame-Options: SAMEORIGIN');

OWASP provides PHP examples for setting HTTP security headers.

However, for WordPress, server-level configuration is often preferable when you want headers applied consistently across the website.

If you use PHP, make sure the headers are sent before output begins.

Do not add security headers in multiple places without checking the final response because duplicate or conflicting headers can create unexpected behavior.

How to Configure WordPress Security Headers Using a WordPress Plugin

Beginners may prefer using a WordPress security or headers plugin instead of editing server configuration manually.

This can be easier if you do not have hosting-level access.

However, before installing a plugin, check:

• Plugin reputation
• Last update
• Compatibility
• Developer activity
• Security history
• Required permissions
• Whether it duplicates another security plugin

Installing too many security plugins can create configuration conflicts.

If you are managing a WordPress website professionally, it is also useful to review the Livasys WordPress Development services, which include WordPress development, maintenance, and security-related work.

For broader website maintenance, you can also refer to Livasys Website Maintenance services.

How to Configure WordPress Security Headers With Content Security Policy

CSP deserves special attention because an incorrect policy can break a WordPress website.

Suppose your website loads:

yourdomain.com
fonts.googleapis.com
fonts.gstatic.com
www.google-analytics.com
cdn.example.com

A restrictive CSP that allows only:

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

may cause some external resources to stop working.

Therefore, when learning How to Configure WordPress Security Headers, do not treat CSP as a copy-and-paste configuration.

Start by identifying the resources your website actually needs.

You can use a reporting policy during testing:

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

Content-Security-Policy-Report-Only allows you to observe violations without enforcing the policy. OWASP documents this as a way to test CSP before moving to enforcement.

A safer workflow is:

Create CSP
   ↓
Use Report-Only
   ↓
Check Violations
   ↓
Identify Required Resources
   ↓
Adjust Policy
   ↓
Test Website
   ↓
Move to Enforcement

This approach is especially useful for WordPress websites with multiple plugins and third-party services.

How to Configure WordPress Security Headers With HSTS

HSTS should be enabled only after your website is correctly configured for HTTPS.

First confirm:

• The main website works on HTTPS.
• HTTP redirects correctly to HTTPS.
• Images use HTTPS.
• CSS uses HTTPS.
• JavaScript uses HTTPS.
• API connections use HTTPS.
• Important subdomains support HTTPS if you plan to use includeSubDomains.

A starting configuration can be:

Strict-Transport-Security: max-age=86400

After confirming the setup works, organizations may choose a longer duration.

OWASP provides HSTS examples and warns that long HSTS durations can make recovery from HTTPS configuration mistakes more difficult.

Do not add includeSubDomains or pursue HSTS preload requirements until you understand the impact on all relevant subdomains.

This is an important safety consideration in How to Configure WordPress Security Headers.

How to Configure WordPress Security Headers Without Breaking Your Website

Security headers can improve security, but incorrect configuration can also break website functionality.

Common problems include:

• Google Fonts not loading
• Analytics scripts failing
• Payment gateways not working
• Embedded videos being blocked
• Chat widgets failing
• Social media embeds breaking
• Plugin dashboards malfunctioning
• AJAX requests being blocked
• REST API functionality failing

This is especially common with CSP.

For this reason, How to Configure WordPress Security Headers should always include testing.

Test:

• Homepage
• Contact forms
• Login
• WordPress dashboard
• Search
• Checkout
• Payment gateway
• Images
• Videos
• Fonts
• Analytics
• Chat widgets
• Embedded content
• REST API
• Mobile version

How to Configure WordPress Security Headers for an E-Commerce Website

E-commerce websites need additional caution.

An online store may use:

• Payment gateways
• Customer accounts
• Third-party analytics
• Product images
• CDN services
• Chat software
• Marketing tools
• Shipping APIs
• Payment JavaScript

A restrictive CSP may accidentally block payment or analytics resources.

Therefore, test all checkout functionality after configuring headers.

You can also connect security-header work with a broader website security and maintenance strategy. Livasys describes website maintenance as including updates and security measures for WordPress websites.

How to Configure WordPress Security Headers for WordPress Admin

The WordPress administration area contains sensitive functionality.

However, you should be careful when applying restrictive headers globally.

Some plugins may use:

• Inline scripts
• Inline styles
• AJAX
• REST API requests
• Embedded frames
• External JavaScript
• Third-party services

A security policy that works perfectly on the public website may cause problems inside /wp-admin/.

Therefore, test both:

Public Website
+
WordPress Dashboard

when implementing How to Configure WordPress Security Headers.

Do not assume that a header configuration is safe simply because the homepage works.

How to Configure WordPress Security Headers and Remove Unnecessary Headers

Security is not only about adding headers.

It can also involve removing unnecessary information.

For example, OWASP recommends removing or minimizing technology-disclosure headers such as X-Powered-By. It also recommends removing or setting non-informative Server values where appropriate.

For example, you may see:

X-Powered-By: PHP/8.x

Exposing technology information does not automatically create a vulnerability, but reducing unnecessary information can make server fingerprinting less useful.

This should be treated as a defense-in-depth measure rather than a primary security control.

How to Configure WordPress Security Headers and Check Cache Behavior

Security headers can interact with caching layers.

WordPress websites may use:

• Browser caching
• CDN caching
• Server caching
• WordPress caching plugins
• Reverse proxies

After changing security headers, clear relevant caches.

The basic workflow is:

Change Headers
    ↓
Clear WordPress Cache
    ↓
Clear CDN Cache
    ↓
Clear Server Cache
    ↓
Test Headers Again

If you update the header at the server level but a CDN continues serving an older cached response, you may think the configuration did not work.

Therefore, cache management should be part of How to Configure WordPress Security Headers.

How to Configure WordPress Security Headers and Verify Them

After configuration, do not assume the headers are active.

You should verify the actual HTTP response.

You can inspect headers using browser developer tools.

In Chrome:

1. Open your website.
2. Right-click the page.
3. Select Inspect.
4. Open the Network tab.
5. Reload the page.
6. Select the main document request.
7. Open Headers.
8. Find the Response Headers section.

You should see something similar to:

Content-Security-Policy: ...
Strict-Transport-Security: ...
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: ...

OWASP also references tools such as Mozilla Observatory and other header-testing tools for inspecting HTTP security headers.

This verification step is essential for How to Configure WordPress Security Headers.

How to Configure WordPress Security Headers With a Testing Workflow

A good beginner-friendly testing workflow looks like this:

1. Take a backup
       ↓
2. Record existing headers
       ↓
3. Add one security header
       ↓
4. Clear caches
       ↓
5. Test website
       ↓
6. Test WordPress admin
       ↓
7. Test forms and integrations
       ↓
8. Verify HTTP response
       ↓
9. Add next header
       ↓
10. Repeat

This is safer than adding ten headers at the same time.

If something breaks, you can identify which change caused the problem.

Common Mistakes When Configuring WordPress Security Headers

When learning How to Configure WordPress Security Headers, beginners should avoid these mistakes.

1. Copying a CSP From Another Website

Every website has different scripts, fonts, APIs, and integrations.

2. Enabling HSTS Too Aggressively

Incorrect HSTS configuration can cause HTTPS access problems.

3. Using Both Plugins and Server Configuration Without Checking

Duplicate or conflicting headers can produce unexpected results.

4. Not Testing WordPress Admin

A header can work on the public site while breaking dashboard functionality.

5. Not Clearing Caches

Old headers may continue to be served.

6. Assuming Security Headers Replace a Firewall

Headers provide browser-level controls. They do not replace firewalls, malware protection, authentication, backups, or secure coding.

7. Using X-XSS-Protection

Modern security guidance generally recommends not relying on this legacy header. OWASP recommends disabling it rather than using it as a primary XSS defense.

8. Using Deprecated Headers

For example, Expect-CT and HPKP are no longer appropriate choices for modern websites. OWASP recommends not using them.

Avoiding these mistakes makes How to Configure WordPress Security Headers safer and easier to manage.

Recommended WordPress Security Headers

There is no single header configuration that is perfect for every WordPress website.

A reasonable starting point for many HTTPS websites could look like:

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

For CSP, start with a carefully tested policy rather than blindly copying a generic example:

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

Then identify legitimate external resources and build the policy around the actual website.

OWASP’s HTTP Headers Cheat Sheet provides detailed recommendations for these headers and explains that different headers address different browser security concerns.

WordPress Security Headers Checklist

Use this checklist when implementing How to Configure WordPress Security Headers:

• Confirm the website uses HTTPS.
• Take a complete website backup.
• Record existing HTTP response headers.
• Configure X-Content-Type-Options.
• Configure an appropriate Referrer-Policy.
• Configure X-Frame-Options if appropriate.
• Consider CSP.
• Test CSP in Report-Only mode first.
• Configure HSTS carefully.
• Consider Permissions-Policy.
• Review COOP/COEP/CORP requirements before enabling them.
• Remove unnecessary technology-disclosure headers where appropriate.
• Clear WordPress and CDN caches.
• Test the public website.
• Test the WordPress dashboard.
• Test forms.
• Test checkout.
• Test third-party integrations.
• Check REST API functionality.
• Inspect actual response headers.
• Recheck headers after future server or plugin changes.

Internal Links for WordPress Security

Internal links are useful for helping readers move between related security and development topics.

For readers who want professional WordPress development support, you can link to Livasys WordPress Development. The page covers WordPress development, maintenance, malware removal, bug fixing, updates, and security-related work.

When discussing server configuration, hosting, HTTPS, and response headers, you can also link to Livasys Web Hosting Services.

For general development topics, link to Livasys Web Development Services.

For website maintenance and ongoing security updates, link to Livasys Website Maintenance Services.

You can also connect this article with related blog articles on your website, such as:

• How to Restrict Admin Access on a Website
• How to Audit WordPress Plugins for Security Risk
• How to Create a Secure Backup Strategy for a Website
• How to Secure API Keys in Web Applications

If those articles are already published on your domain, use their exact URLs as internal links.

External Resources for WordPress Security Headers

For authoritative information about How to Configure WordPress Security Headers, the following resources are useful.

The OWASP HTTP Headers Cheat Sheet provides detailed guidance for security headers including CSP, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, COEP, and CORP.

For Content Security Policy, read the OWASP Content Security Policy Cheat Sheet. It explains CSP enforcement and Report-Only mode.

For HSTS, see the OWASP HTTP Strict Transport Security Cheat Sheet.

MDN also provides a current HTTP Headers reference covering headers such as HSTS, Permissions-Policy, and X-Content-Type-Options.

The OWASP Secure Headers Project provides additional explanations, implementation guidance, and testing resources.

These are standard external resources and can be used as DoFollow links when inserted as normal hyperlinks without nofollow, sponsored, or ugc attributes.

Frequently Asked Questions

What are WordPress security headers?

WordPress security headers are HTTP response headers that provide security-related instructions to browsers. They can help control HTTPS usage, resource loading, framing, MIME-type handling, referrer information, and browser features.

What is the most important WordPress security header?

There is no single header that is most important for every website. HSTS, CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, and Permissions-Policy each address different security concerns.

Can I configure WordPress security headers without a plugin?

Yes. Depending on your hosting environment, you can configure headers using Apache .htaccess, Nginx configuration, PHP, a hosting control panel, CDN settings, or other server-level mechanisms.

Should beginners use Content Security Policy?

Beginners can use CSP, but they should introduce it carefully. CSP can break legitimate scripts and integrations if configured incorrectly. Using Content-Security-Policy-Report-Only during testing can help identify required resources before enforcement.

Does HTTPS automatically configure all security headers?

No. HTTPS encrypts communication, but it does not automatically configure every security header. HSTS is an additional response-header policy that tells compatible browsers to use HTTPS.

Can security headers improve WordPress security?

Yes. Security headers can provide additional browser-level protections against certain classes of attacks. However, they should be combined with secure authentication, updates, backups, access controls, secure coding, and monitoring.

Can security headers break a WordPress website?

Yes. Incorrect CSP, iframe restrictions, cross-origin policies, or other configurations can interfere with plugins, themes, analytics, payment gateways, fonts, APIs, and embedded content. Always test changes before applying them broadly.

How can I check whether my security headers are working?

You can inspect the response headers through your browser’s developer tools or use security-header testing tools. OWASP lists several tools for inspecting and testing HTTP security headers.

Final Thoughts

How to Configure WordPress Security Headers is an important part of building a stronger WordPress security strategy. Security headers allow your server to communicate security instructions to modern browsers and can provide an additional layer of protection.

The most important steps are:

1. Make sure your website uses HTTPS.
2. Understand each security header before enabling it.
3. Start with simple headers such as X-Content-Type-Options and Referrer-Policy.
4. Configure X-Frame-Options when appropriate.
5. Use HSTS carefully.
6. Introduce CSP gradually.
7. Test CSP in Report-Only mode before enforcement.
8. Use Permissions-Policy to restrict unnecessary browser features.
9. Consider advanced cross-origin policies only when your website needs them.
10. Avoid deprecated security headers.
11. Clear caches after configuration changes.
12. Test the public website and WordPress dashboard.
13. Test forms, checkout, APIs, and third-party integrations.
14. Verify the actual HTTP response headers.
15. Recheck your configuration after major plugin, theme, server, or hosting changes.

The biggest lesson from How to Configure WordPress Security Headers is that security headers should be configured based on how your website actually works. A strict-looking configuration is not necessarily a good configuration if it breaks legitimate functionality.

For beginners, start small, make one change at a time, test carefully, and document your configuration.

A practical security workflow is:

HTTPS
  ↓
Security Headers
  ↓
Authentication
  ↓
Access Control
  ↓
Plugin & Theme Updates
  ↓
Backups
  ↓
Monitoring
  ↓
Regular Security Testing

By following this approach, you can make How to Configure WordPress Security Headers a repeatable part of your WordPress security and website maintenance process rather than a one-time configuration task.