How to Block All Third-Party Requests on Your WordPress Site with a Strong Content Security Policy (CSP)

As a WordPress site owner you have the problem, that a lot of Plugins and Themes load JavaScript or CSS from external servers. And even if you managed to configure and adjust everything, that they do not do that anymore, with the next Plugin update it might be already changed.

If you prioritize GDPR compliance and want to ensure no third-party resources are ever loaded, the most powerful technical control you can apply is a Content Security Policy (CSP).

If you wonder: What the heck? Why I should even bother about 3rd party request, read this article which explains why 3rd party requests might be problematic: 3rd party request and user privacy.

This guide walks you through how to use a CSP to stop external scripts, fonts, iframes, and other third-party requests from loading by default – putting you in full control of what runs on your WordPress site. Please watch out for the Caveats at the end of this article.

💡 What Is a Content Security Policy (CSP)?

A CSP is an HTTP header that tells the browser which sources of content (like scripts, images, iframes) are allowed to load. Everything else gets blocked.

When configured strictly, a CSP:

  • Blocks unintended data sharing with third parties (e.g. Google, Facebook)
  • Prevents accidental non-compliance with GDPR and other privacy regulations
  • Acts as a security layer against XSS (cross-site scripting)

🛠️ The Strict Privacy-First CSP Header

To block all third-party requests and only allow assets from your own domain (plus a few safe exceptions like inline CSS/JS and local data URIs), you can set the following CSP header:

Header set Content-Security-Policy "default-src 'self' data: 'unsafe-inline' 'unsafe-hashes' 'unsafe-eval'; frame-src 'self' blob:;"

📌 What this CSP does:

  • 'self' → Only allows content from your own domain
  • data: → Allows inline images like base64-encoded logos or icons
  • 'unsafe-inline', 'unsafe-hashes', 'unsafe-eval' → Needed for legacy WordPress themes/plugins (you can tighten these later)
  • frame-src 'self' blob: → Allows self-hosted iframe content, blocks YouTube, Vimeo, etc.

🚫 This will block:

  • Google Fonts, Google Analytics
  • YouTube and Vimeo embeds
  • Facebook Pixel, Twitter embeds
  • External ad networks, CDNs, etc.
  • Actually anything which does not come from your own domain.

📍 How to Add the CSP Header in WordPress

Option 1 – in server configuration – recommended

Via .htaccess (Apache servers)

Add this to your .htaccess file in the root of your WordPress install:

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self' data: 'unsafe-inline' 'unsafe-hashes' 'unsafe-eval'; frame-src 'self' blob:;"
</IfModule>
NGINX Configuration

Add this to your site’s server block (e.g., in /etc/nginx/sites-available/example.com):

add_header Content-Security-Policy "default-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; frame-src 'self' blob:;" always;

💡 Don’t forget to reload NGINX:

sudo nginx -t && sudo systemctl reload nginx

Option 2: Via WordPress Plugin

The WordPress plugin ‘3rd Party Request Manager‘ is designed to help you set Content Security Policy (CSP) headers in WordPress – and it even automatically detects third-party requests.

Other plugins who are not that specialized, but also get the job done:

These let you define headers without editing files manually.

🧪 Testing Your CSP

After setting your CSP:

  1. Open your site in Chrome
  2. Go to DevTools → Network & Console tabs
  3. Look for CSP violations in the console

Also test with:

⚠️ Important Caveats

  • Some WordPress themes and plugins rely on inline styles or scripts. A strict CSP may break visual elements or interactions.
  • You may need to adjust or whitelist some scripts using 'nonce-<random>' or 'sha256-<hash>' if you remove 'unsafe-inline'.
  • Blocked content may include YouTube embeds, Google Maps, external fonts, payment widgets, or Web Tracking.

For GDPR compliance, that’s actually the point – don’t allow any third-party data transfer. In some cases, for example payment provider you need to allow their scripts.

This is an example how the CSP would look like:

Header set Content-Security-Policy "default-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' js.stripe.com; frame-src 'self' blob: js.stripe.com checkout.stripe.com;"

This are serious caveats of the solution, but the advantage is: you can sleep calmly as you know: it is now technically impossible to load 3rd party scripts, doesn’t matter what a plugin or WordPress update changes.

How to overcome the Caveats

This is a huge topic, but in general: have a look at all the JavaScripts, CSS and other resources loaded from a 3rd Party and host them locally. You can do that manually, with these steps:

  1. Download them
  2. Upload them on your server
  3. Inject them on your page. This is done best with WordPress hooks.

Please be aware that this principle might not work with all 3rd Party ressources and that the 3rd Party does not allow that in their terms and condition.

☝ If you need technical support with that please reach out to us, we are happy to help.

All prices incl. VAT.