CSP allowing all Google domains?

Question

I'm trying to develop a CSP for the site https://www.lidl-tour.ro.

Right now there is a policy than runs in report-only-mode, so nothing is blocked at the moment.

The site contacts googleads.g.doubleclick.net and stats.g.doubleclick.net. So I have put these hosts on the whitelist.

But it seems that these sites then (make the user) load content from www.google.com and www.google.YOURTLD. I can see CSP violations being reported where the browser wanted to contact https://www.google.com.cy, https://www.google.co.uk, https://www.google.it, https://www.google.de and so on.

Now I don't want to put all google domains into the CSP.

I thought about allowing https://www.google.* (I don't know if this is even valid in a CSP) but this expression wouldn't match URLs like https://www.google.co.uk.

So, how can I build a valid CSP in this case?

Answer 1

As an addition - not only is it not supported, you wouldn't want it even if it was supported.

Because https://www.google.* would then match not only https://www.google.co.uk but also https://www.google.evilattacker.com. And you can be sure that is exactly the URL attackers would use, as it would give them best leverage against CSP on majority of sites.

Answer 2

I hope that Google reads this too, they should change GoogleAds and Google Analytics by serving these images from ar.images.google.com and be.images.google.com, then we can set up our CSP using image-src: 'self' *.images.google.com. This is because using the current CSP standard we cannot use a wildcard for the top-level domain in the Content-Security-Policy header, only on the hostname. And for Google analytics it looks like a change without a lot of impact.

Btw: Sentry.com offers a CSP reporting url.

Answer 3

The problem here isn't with your CSP, but more to do with how the aims of CSP and Google Analytics and similar tracking systems are at odds with one another.

The Content-Security-Policy header was designed under the assumption that site owners know and control all content that is executed on their pages, and that it's therefore possible to exclude everything else. This isn't really the case with tracking and advert code on pages, where a third party is running their code too.

For "high security" applications, such as internet banking websites, payment processors, and similar, it's often possible to minimise the number of third party systems used - banks will tend to run their own analytics systems, rather than using Google's, and won't have third party adverts on pages within the internet banking application. That points to one option to have a valid CSP: host your own tracking and advertising code on a domain you control. This isn't always viable for a smaller business.

You could also look to move secure elements of your site to a subdomain, and apply a strict CSP to that, with a more relaxed policy on the open parts. This would mean that static content, or content which you are confident can't be modified or added to by users, could be served with adverts/tracking, while authenticated sections, or sections where user content is displayed, could be restricted to known domains. It's not perfect, but it's better than an open CSP allowing all hostnames.

Answer 4

Each Google top-level domain (TLD) must be specified individually, since CSP syntax does not allow the use of wildcards on the right side of the hostname. A list of all supported Google TLDs is available at: https://www.google.com/supported_domains.

Answer 5

Have you considered using an online tool e.g. report-uri?

[updated]

Host wildcards aren't legal (see this spec):

Each source expression's host name MAY contain up to one wildcard (*) and it MUST be the left-most DNS label.

Have you considered serving your web pages with a different CSP header depending on the users' geolocation? So people from the UK would get a CSP that allows *.google.co.uk, and so on.