How to Set Up Content Security Policy (CSP) in WordPress with WP Ghost
This tutorial has moved to the new WP Ghost Knowledge Base where each feature is presented in detail.
Add a Content Security Policy (CSP) to your WordPress site with WP Ghost (formerly Hide My WP Ghost) to control which sources can load scripts, styles, images, and fonts on your pages. CSP is the most powerful HTTP security header for preventing Cross-Site Scripting (XSS) and data injection attacks. WP Ghost lets you set it in one field with no code editing.
According to Patchstack’s 2026 report, 47.7% of all WordPress vulnerabilities are Cross-Site Scripting (XSS). CSP blocks these attacks at the browser level by restricting where scripts and resources can load from. If an attacker injects a malicious script, the browser refuses to execute it because the script’s source is not in the allowed list.
What Is Content Security Policy?
CSP is an HTTP response header that tells the browser which sources of content are allowed on your pages. You define rules (called directives) that specify where scripts, stylesheets, images, fonts, frames, and other resources can come from. If any content violates the rules, the browser blocks it from loading.
By default, WP Ghost sets a basic CSP that blocks plugins and Flash objects:
object-src 'none';You can customize this to be as restrictive as your site requires.
How to Set CSP in WordPress with WP Ghost
Go to WP Ghost > Firewall > Header Security. Switch on Add Security Headers for XSS and Code Injection Attacks if not already enabled. Find the Content-Security-Policy field. Enter your CSP rules. Click Save.
After saving, verify your headers at SecurityHeaders.com by entering your domain. You can also check in your browser’s DevTools (Network tab, select any request, look at the Response Headers section).
CSP Examples for WordPress
Basic CSP (WP Ghost Default)
Blocks all plugins and Flash objects. This is what WP Ghost sets by default when you enable security headers:
object-src 'none';Recommended WordPress CSP
A balanced CSP for most WordPress sites. Allows resources from your own domain, permits inline styles and scripts (required by many WordPress themes and plugins), blocks iframes and Flash objects:
default-src https: 'unsafe-inline' 'self' data:; base-uri 'self'; frame-ancestors 'none'; object-src 'none';This is a good starting point for the WordPress admin area and most front-end themes. It allows HTTPS resources, inline scripts/styles (which WordPress and most page builders require), and data URIs for inline images.
Strict CSP with Third-Party Services
If you want tighter control, specify each content type individually. Adjust the domains to match your actual third-party services:
default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self'; img-src 'self' https://images.example.com; font-src https://fonts.googleapis.com; connect-src 'self'; frame-src 'self'; object-src 'none';Replace the example domains with your actual CDN, image hosting, font provider, and analytics service. Common domains you may need to add: https://www.google-analytics.com (analytics), https://fonts.googleapis.com (Google Fonts), https://js.stripe.com (Stripe payments), https://www.googletagmanager.com (GTM).
CSP Directives Quick Reference
| Directive | Controls | Common values |
|---|---|---|
| default-src | Fallback for all resource types | ‘self’, https: |
| script-src | JavaScript files | ‘self’, ‘unsafe-inline’, CDN domains |
| style-src | CSS files | ‘self’, ‘unsafe-inline’, font domains |
| img-src | Images | ‘self’, data:, CDN domains |
| font-src | Web fonts | ‘self’, https://fonts.gstatic.com |
| connect-src | AJAX, WebSocket, fetch() | ‘self’, analytics domains |
| frame-src | Iframes | ‘self’, ‘none’, video embed domains |
| object-src | Flash, plugins | ‘none’ (always) |
| base-uri | Base URL for relative URLs | ‘self’ |
| frame-ancestors | Who can embed your page | ‘none’, ‘self’ |
Troubleshooting
A third-party service stopped working after enabling CSP
If Google Analytics, a payment gateway, live chat widget, or embedded video stops working, the CSP is blocking that domain’s resources. Open your browser’s DevTools Console (F12). CSP violations appear as error messages telling you exactly which domain and directive was blocked. Add the required domain to the appropriate directive (e.g., add https://www.google-analytics.com to script-src).
Page builder preview or iframes not loading
If your page builder’s preview or an iframe embed stops working, the frame-ancestors or X-Frame-Options directive is likely set to ‘none’ or DENY. Change frame-ancestors to ‘self’ in your CSP to allow framing by your own domain. In WP Ghost, also check that X-Frame-Options is set to SAMEORIGIN.
Inline scripts or styles are blocked
Many WordPress themes and plugins use inline scripts and styles. If your site layout breaks after enabling a strict CSP, add ‘unsafe-inline’ to both script-src and style-src. While this reduces CSP strictness, it is necessary for most WordPress sites to function correctly. The Recommended WordPress CSP example above includes this.
Frequently Asked Questions
Is ‘unsafe-inline’ really safe to use?
It is less strict than a CSP without it, but it is still much better than no CSP at all. Most WordPress themes and plugins inject inline scripts and styles. Without ‘unsafe-inline’, these break. The practical choice for most WordPress sites is to allow inline content while restricting external sources. This still blocks injected scripts from unknown domains.
Which headers does WP Ghost enable besides CSP?
WP Ghost enables seven security headers with a single toggle: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Cross-Origin-Embedder-Policy (COEP), and Cross-Origin-Opener-Policy (COOP). CSP is the only one that typically needs customization. See the Header Security tutorial for all seven headers.
How do I test if my CSP is working?
Visit SecurityHeaders.com and enter your domain. It scans your HTTP response headers and grades each one. You can also open your browser’s DevTools (F12), go to the Console tab, and look for CSP violation errors. Each violation tells you exactly which directive blocked which resource.
Will CSP affect my SEO?
Not directly. Security headers have zero impact on page load time or rendering speed. However, Google Lighthouse includes security headers in its audit, so having them configured contributes to a better Lighthouse score. HSTS (which WP Ghost also enables) contributes to HTTPS enforcement, which is a confirmed Google ranking signal.
Do I need to configure CSP differently for WooCommerce?
If you use Stripe, PayPal, or other payment gateways, you need to add their domains to your CSP. For Stripe, add https://js.stripe.com to script-src and https://api.stripe.com to connect-src. For PayPal, add https://www.paypal.com and https://www.paypalobjects.com. Check your payment gateway’s documentation for required domains.
Can I use CSP in report-only mode first?
Yes. Instead of Content-Security-Policy, use Content-Security-Policy-Report-Only as the header name. This logs violations in the browser console without actually blocking anything. It lets you audit what would be blocked before enforcing the policy. Note that WP Ghost’s built-in field sets the enforcing header; for report-only mode, you would add the header manually or via your hosting configuration.
Does WP Ghost modify WordPress core files to add headers?
No. Headers are added through server configuration and PHP output. No core files are modified. Disabling the security headers toggle removes all headers instantly.
Related Tutorials
Header Security – all seven security headers WP Ghost enables (HSTS, CSP, X-Frame-Options, and more).
Firewall and Geo Security – the 8G Firewall and injection protection that complement CSP.
Activate Security Tweaks – hide WordPress fingerprints and remove unsafe headers.
Customize All WordPress Paths – path security that works alongside header security.
Website Security Check – verify your overall security configuration.
