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?

  • 2
    Have you had a look at [this][1] answer? Looks like your question is quite similar. [1]: stackoverflow.com/questions/34361383/…
    – Wietze
    Commented Jan 27, 2017 at 10:02
  • Thank you for the comment. The problem is very similar, indeed.
    – HorstKevin
    Commented Jan 27, 2017 at 13:39
  • The problem is not your CSP, it is how promiscuous those cross-site-requests have become. I installed a request policy addon to my browser last week, and the amount of different domains being pulled by a single page is baffling. Commented Jan 27, 2017 at 14:28
  • i've not tried this, but perhaps you could use the HTML endpoint and some JS to dynamically set your policy after sniffing the TLD: <meta http-equiv="Content-Security-Policy" content="...">
    – dandavis
    Commented Feb 1, 2017 at 20:18

5 Answers 5


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.

  • Good point you have here. Commented May 26, 2018 at 13:28
  • Good point indeed. Commented Mar 22, 2022 at 16:28
  • Very good point.
    – Tom Wright
    Commented yesterday

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.


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.


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.

  • 1
    Just amazed that they're asking users to allow all those google.<TLD> 's.
    – mamacdon
    Commented May 30, 2023 at 22:11

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


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.

  • Yes, I have. There I see the violations against my current policy. I'm not sure that I understand your point.
    – HorstKevin
    Commented Jan 27, 2017 at 12:57
  • 1
    @HorstKevin I wasn't trying to make any particular point, but looked like you were trying to write your own policy by hand. Regarding your problem, wildcards on the left-hand side of a domain are the only one allowed. See wiki.mozilla.org/Security/CSP/Specification#Hostname_Wildcards "Each source expression's host name MAY contain up to one wildcard (*) and it MUST be the left-most DNS label."
    – lorenzog
    Commented Jan 27, 2017 at 13:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .