A Content Security Policy (CSP) stops third-party vendors from loading damaging features on your website, thereby improving security. However, if you continue to use Google Analytics with a CSP enabled, you will need to make some modifications.

The good news is that these are simple to apply, not to mention well worthwhile.

Enabling Google Analytics

Before you start, it’s important to know that you must make modifications to your existing policy. Never add a second policy.

Another thing to do is ensure that you stick to the directive names already in your policy. If any of the directives we talk about below are not present in your CSP, don’t add them. If you do, your CSP may start restricting resources that are currently allowed to load, causing things to go missing on your website.

How to Use a Content Security Policy with Google Analytics

Features to Allow


The script-src directive restricts Google Analytics from running JavaScript. To lift this restriction, add https://www.google-analytics.com to the source list. You may also want to add http://www.google-analytics.com for development purposes. In addition, you need to add the Google Analytics code snippet to you add to the page. This begins with (function(i,s,o,g,r,a,m).

The most secure way to allow Google Analytics to run is to use a nonce-value on the inline script. However, as this is complicated, you should only opt for this method if you are already using nonce-values for other inline scripts. An easier option is to move the Google Analytics code snippet to an external code file hosted on a domain that the CSP has already allowed in the script-src directive. The good news is that if you are using Google Tag Manager, this is already complete.

In a hurry to implement freshly-discovered knowledge on your website?
Contact the InsightWhale team to configure GA Content Security Policy for you 🙂

Yet another alternative is to add the string ‘unsafe-inline’ to the script-src directive source list. This is the simplest option, but it will allow all inline snippets to run, meaning code you want to block may still run.

Tracking Beacons

You also need to remove restrictions to enable Google Analytics to send data to Google servers for Image requests and Post requests and to use the browser Beacon feature. Whitelist https://www.google-analytics.com, plus https://stats.g.doubleclick.net and https://www.google.com if you have Advertising Features or AdWords integration. For Image requests, add to the source list for the img-src directive. For the other two, add to the connect-src directive. For instance:

script-src 'self' https://www.google-analytics.com;
img-src https://www.google-analytics.com www.google-analytics.com https://stats.g.doubleclick.net;
connect-src https://www.google-analytics.com www.google-analytics.com https://stats.g.doubleclick.net

This will only allow what is necessary for your site to become whitelisted. It does mean that you need to move the Google Analytics code snippet to a separate file hosted on the same domain as your website.

There is also a simpler option. It looks like this:

default-src 'self' https://www.google-analytics.com 'unsafe-inline'

This is slightly less secure, but it will block all non-Google resources.

There is no reason to feel like using a CSP is too much trouble. It takes just a few steps to modify your CSP to work with Google Analytics and you’ll have much better security for your website.