CSP for Third Party Scripts: Google Analytics, Tag Manager, and Payment Providers

How third party scripts interact with CSP#

A Content Security Policy is a single HTTP header your server sends with every page response. It contains a list of directives, and each directive controls which domains are allowed for a specific type of resource. Here is the basic format:

Content-Security-Policy:
  script-src 'self' cdn.example.com;
  connect-src 'self' api.example.com;
  img-src 'self' images.example.com;
  frame-src 'self' embed.example.com

Each directive name (script-src, connect-src, img-src, frame-src) tells the browser which resource type that rule applies to. 'self' means your own domain. After that, you list the external domains that are allowed. Directives are separated by semicolons, and domains within a directive are separated by spaces.

With that in mind, here are the four ways third party scripts can trigger CSP violations:

• Loading the script itself. The initial <script src="..."> tag loads from an external domain. If that domain is not listed in the script-src directive of your CSP, the browser blocks it.
• Making API calls. Once loaded, the script sends data back to its servers using XHR or fetch. The connect-src directive in your CSP controls which domains the browser allows these network requests to reach.
• Creating iframes. Payment forms and embedded widgets often run inside an iframe. The frame-src directive in your CSP decides which domains are allowed to be embedded as iframes on your page.
• Loading additional resources. The script may load images (tracking pixels), styles, or additional scripts from other domains. Each resource type is governed by its own CSP directive: img-src for images, style-src for stylesheets, and script-src for JavaScript files.

Analytics and tracking#

Google Analytics (GA4)

Google Analytics 4 is typically loaded through Google Tag Manager, but it can also be loaded directly. Here are the domains it needs:

Google Tag Manager

Google Tag Manager is the tricky one. GTM itself loads from a known domain, but the tags it fires can load scripts from anywhere. This is where 'strict-dynamic' becomes essential.

Facebook Pixel

Hotjar

Payment providers#

Payment providers are especially sensitive to CSP misconfigurations. If the checkout form fails to load, you lose revenue immediately. Always test payment flows thoroughly after deploying or updating your CSP.

Stripe

PayPal

Square

Customer support and engagement#

Intercom

HubSpot

Crisp Chat

Common web services#

Google Fonts

Google reCAPTCHA (v2 and v3)

YouTube Embeds

Google Maps

Putting it all together: a real world example#

Here is what a CSP looks like for a typical SaaS marketing site that uses Google Tag Manager (with GA4), Stripe for payments, Intercom for support, Google Fonts, and reCAPTCHA on the contact form:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{value}' 'strict-dynamic'
    www.googletagmanager.com
    www.google.com www.gstatic.com
    js.stripe.com
    widget.intercom.io js.intercomcdn.com;
  style-src 'self' 'nonce-{value}'
    fonts.googleapis.com;
  font-src 'self'
    fonts.gstatic.com
    js.intercomcdn.com;
  img-src 'self' data: https:
    www.googletagmanager.com
    www.google-analytics.com
    static.intercomassets.com *.intercomcdn.com
    *.stripe.com;
  connect-src 'self'
    www.google-analytics.com analytics.google.com
    *.google-analytics.com *.analytics.google.com
    api.stripe.com
    *.intercom.io wss://*.intercom.io;
  frame-src 'self'
    www.google.com
    js.stripe.com hooks.stripe.com
    intercom-sheets.com;
  media-src 'self'
    js.intercomcdn.com;
  report-uri /api/csp-report

This is a long policy, and that is normal. Real world CSPs with multiple third party services are not short. The important thing is that every domain is explicitly listed for the specific directives it needs. No wildcards on broad domains, no unsafe-inline in script-src, and strict-dynamic handles dynamic script loading.

Best practices for managing third party scripts in CSP#

How to find domains you are missing#

Even with this reference, your site might use services not listed here. Here is how to discover what domains your CSP needs:

• Browser DevTools Network tab. Open your site, go to the Network tab, and reload. Filter by domain to see every external domain your page contacts. Each one might need to be in your CSP.
• CSP violation reports. Deploy your policy in Content-Security-Policy-Report-Only mode with a report-uri endpoint. The browser will tell you exactly what is being blocked and which directive caused it.
• Run a scan. SiteSecurityScore scans your site and shows your current CSP, what it covers, and what might be missing.
• Check the service's documentation. Many services now publish their CSP requirements. Stripe, Google, and others have documentation pages listing the exact domains their scripts use.

The bottom line#

Third party scripts are the most common reason CSP deployments fail. Not because the concept is hard, but because finding the right domains for each service is tedious and error prone. This guide gives you the starting point. Combine it with Content-Security-Policy-Report-Only mode to catch anything you missed, and you will have a production ready CSP that protects your users without breaking your integrations.

Remember that third party services change their infrastructure over time. Bookmark this page, but also keep your CSP reporting active. The combination of a good reference and real time violation data is what makes CSP manageable at scale.

Frequently asked questions#