How to Add Security Headers in WordPress with WP Ghost

Wp Ghost Header Security
Table of Contents

Add HTTP security headers to your WordPress site with one toggle in WP Ghost. Security headers are directives in your server’s HTTP response that instruct browsers how to handle your content. They prevent cross-site scripting (XSS), clickjacking, MIME type sniffing, and protocol downgrade attacks. Without them, your site relies entirely on the browser’s default behavior – which is permissive. WP Ghost adds seven security headers through the configuration file and PHP, covering the protections that security auditors and tools like SecurityHeaders.com check for.

What Are Security Headers?

What are HTTP security headers and how WP Ghost adds them to protect against XSS and clickjacking

Security headers are directives included in the HTTP response from your web server. They tell the browser what it’s allowed to do with your page content – which domains can load scripts, whether the page can be embedded in an iframe, whether to enforce HTTPS, and how to handle MIME types. Each header addresses a specific attack vector.

Without security headers, browsers apply default (permissive) policies. Attackers exploit these defaults to inject scripts, embed your pages in malicious iframes, or trick browsers into executing files with incorrect MIME types. Security headers close these gaps by setting explicit policies at the browser level.

SecurityHeaders.com scan result showing security header grades

Why Security Headers Matter

Security headers are a fundamental web security practice. Here’s why they’re essential for your hack prevention strategy:

They prevent browser-level attacks. WP Ghost’s firewall blocks malicious requests at the server level. Security headers protect at the browser level – they prevent attacks that happen after the page has loaded, like injected scripts executing in a visitor’s browser or your page being embedded in a malicious site.

Security auditors and scanners check for them. Tools like SecurityHeaders.com, Qualys SSL Labs, and Google Lighthouse grade your site based on security header presence. Missing headers result in lower security scores, which can affect client trust, compliance requirements, and hosting security assessments.

They require zero maintenance once enabled. Unlike firewall rules that need updating, security headers are set-and-forget directives. Once enabled, they apply to every response from your server. No ongoing configuration, no updates needed, no performance impact.

How to Enable Security Headers in WP Ghost

  1. Go to WP Ghost > Overview or WP Ghost > Firewall > Header Security.
  2. Switch on Add Security Headers for XSS and Code Injection Attacks.
  3. Click Save to apply.
WP Ghost Add Security Headers for XSS and Code Injection Attacks toggle

WP Ghost adds all seven security headers through the configuration file and PHP. After enabling, test your headers at SecurityHeaders.com to verify they’re active.

OpenLiteSpeed users: Additional server-level configuration may be needed. See the guide: Setting Security Headers in OpenLiteSpeed.

Security Headers Reference

Here are the seven security headers WP Ghost adds, what each one protects against, and how to configure them.

Strict-Transport-Security (HSTS)

Forces browsers to access your site only over HTTPS, preventing protocol downgrade attacks and cookie hijacking. Once a browser receives this header, it will not make HTTP requests to your domain for the specified duration. MDN reference.

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

max-age=31536000 sets the duration (1 year in seconds). includeSubDomains applies to all subdomains. preload requests inclusion in browsers’ built-in HSTS list for immediate enforcement.

Content-Security-Policy (CSP)

Controls which sources can load content on your pages – scripts, stylesheets, images, fonts, frames. Prevents XSS by blocking unauthorized script execution. This is the most powerful and complex security header. MDN reference.

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com

default-src 'self' allows resources only from your own domain. script-src 'self' https://apis.google.com allows scripts from your domain and Google APIs. Customize the CSP policy based on which external services your site uses (analytics, fonts, payment gateways, etc.).

CSP requires careful configuration. A restrictive CSP can block legitimate third-party scripts (Google Analytics, payment gateways, live chat, etc.). Test thoroughly after enabling. If a feature breaks, add the required domain to the appropriate CSP directive.

X-Frame-Options

Prevents clickjacking by controlling whether your page can be embedded in <iframe>, <frame>, <embed>, or <object> elements on other sites. MDN reference.

X-Frame-Options: SAMEORIGIN

DENY prevents all framing. SAMEORIGIN allows framing only by your own domain. Use SAMEORIGIN if your site uses iframes internally (some page builders and admin panels require this).

X-XSS-Protection

Enables the browser’s built-in XSS filter, which detects and blocks reflected XSS attacks. While modern browsers rely more on CSP, this header provides backward-compatible protection for older browsers. MDN reference.

X-XSS-Protection: 1; mode=block

1 enables the filter. mode=block instructs the browser to block the page entirely if an XSS attack is detected, rather than attempting to sanitize the page.

X-Content-Type-Options

Prevents MIME type sniffing – where browsers try to “guess” a file’s type regardless of the declared Content-Type. Without this header, an attacker could upload a malicious file disguised with an innocent extension. MDN reference.

X-Content-Type-Options: nosniff

nosniff forces the browser to use the declared MIME type. No guessing, no interpretation, no execution of mistyped files.

Cross-Origin-Embedder-Policy (COEP)

Ensures your document can only load cross-origin resources that explicitly grant permission. Prevents data leaks through embedded content from other domains. MDN reference.

Cross-Origin-Embedder-Policy: require-corp

require-corp requires cross-origin resources to include a Cross-Origin-Resource-Policy header granting access. Resources without this header are blocked.

Cross-Origin-Opener-Policy (COOP)

Isolates your document from cross-origin windows, preventing attacks like cross-origin information leaks and Spectre-type side-channel attacks. MDN reference.

Cross-Origin-Opener-Policy: same-origin

same-origin isolates the browsing context so cross-origin documents cannot interact with your page through window.opener or similar mechanisms.

Troubleshooting

A third-party service stopped working after enabling headers

The most common issue is Content-Security-Policy blocking scripts from external domains. If Google Analytics, a payment gateway, live chat widget, or embedded video stops working, the CSP is blocking that domain’s resources. Add the required domain to the appropriate CSP directive (e.g., add https://www.google-analytics.com to script-src). WP Ghost lets you customize the CSP value directly.

Page builder preview or iframes not loading

If your page builder’s preview or an iframe embed stops working, the X-Frame-Options header is likely set to DENY. Change it to SAMEORIGIN to allow framing by your own domain while still blocking cross-origin framing.

If you’ve lost access or something broke, check the emergency disable guide, use the rollback settings, or add a constant in wp-config.php to disable WP Ghost temporarily.

Frequently Asked Questions

Which headers should I enable?

All of them. WP Ghost enables all seven with a single toggle. The headers are industry-standard security practices. The only one that typically needs customization is Content-Security-Policy, which may need additional domains added if you use third-party services.

How do I verify my headers are working?

Visit SecurityHeaders.com and enter your domain. It scans your HTTP response headers and grades each one. After enabling WP Ghost’s security headers, you should see green marks for all configured headers. You can also check headers in your browser’s DevTools (Network tab → select a request → Headers section).

Do security headers affect performance?

No. Security headers are a few bytes added to the HTTP response. They have zero impact on page load time, rendering speed, or server performance. They’re processed by the browser instantly as part of the HTTP response handling.

Do security headers affect SEO?

Not directly, but HSTS contributes to HTTPS enforcement which is a ranking signal. Security headers can improve your site’s security score, which some hosting providers and enterprise clients evaluate. Google Lighthouse also checks for security header presence in its security audit.

Does WP Ghost modify WordPress core files?

No. Security headers are added through server configuration files (.htaccess) and PHP output headers. No WordPress core files are modified. Disabling the feature removes all security headers instantly.

Complete your server-level defense:

Tagged: