Add way to define all country code top-level domain.

[AndrewStoyan]

For example, I have some sort of google analytics or something similar. If my site is used all over the world I don`t have the opportunity to specify all country codes. It is not possible to list all countries if it requires something like .google. (....google.de, ....google.it, ....google.es).

[michaelficarra]

1. How many organisations own *all** ccTLDs for their trademark? I'm assuming not many.
2. What kind of use case requires listing all of these domains? Can't you know ahead of time which you'll be using?
3. What happens when new ccTLDs are added? I'm assuming it's meant to include future ones, not just those of today. I'm not a fan of adding yet another feature which causes the meaning of a security policy to change over time.

[AndrewStoyan]

Let's say about some world-wide social network. I think it's not charm solution to make a huge list of domains. Maybe CSP should support some kind of regular expressions. Maybe at least in separate parts of URL if not whole.

[mozfreddyb]

Well, sites that support CSP might also just not redirect to country-specific domains for the things they host. In your case, I think there is a dedicated google-analytics.com domain that you can use which does not redirect to a google.(country) domain. Maybe @mikewest knows more?

[AndrewStoyan]

It's google remarketing. Yes, I know about google.com/ncr. But that links specified in external scripts so I can't change them and ncr doesn`t work for that links.

[AndrewStoyan]

Any updates on this?

[laukstein]

Here would be list of Google domains https://www.google.com/supported_domains

.google.com .google.ad .google.ae .google.com.af .google.com.ag .google.com.ai .google.al .google.am .google.co.ao .google.com.ar .google.as .google.at .google.com.au .google.az .google.ba .google.com.bd .google.be .google.bf .google.bg .google.com.bh .google.bi .google.bj .google.com.bn .google.com.bo .google.com.br .google.bs .google.bt .google.co.bw .google.by .google.com.bz .google.ca .google.cd .google.cf .google.cg .google.ch .google.ci .google.co.ck .google.cl .google.cm .google.cn .google.com.co .google.co.cr .google.com.cu .google.cv .google.com.cy .google.cz .google.de .google.dj .google.dk .google.dm .google.com.do .google.dz .google.com.ec .google.ee .google.com.eg .google.es .google.com.et .google.fi .google.com.fj .google.fm .google.fr .google.ga .google.ge .google.gg .google.com.gh .google.com.gi .google.gl .google.gm .google.gp .google.gr .google.com.gt .google.gy .google.com.hk .google.hn .google.hr .google.ht .google.hu .google.co.id .google.ie .google.co.il .google.im .google.co.in .google.iq .google.is .google.it .google.je .google.com.jm .google.jo .google.co.jp .google.co.ke .google.com.kh .google.ki .google.kg .google.co.kr .google.com.kw .google.kz .google.la .google.com.lb .google.li .google.lk .google.co.ls .google.lt .google.lu .google.lv .google.com.ly .google.co.ma .google.md .google.me .google.mg .google.mk .google.ml .google.com.mm .google.mn .google.ms .google.com.mt .google.mu .google.mv .google.mw .google.com.mx .google.com.my .google.co.mz .google.com.na .google.com.nf .google.com.ng .google.com.ni .google.ne .google.nl .google.no .google.com.np .google.nr .google.nu .google.co.nz .google.com.om .google.com.pa .google.com.pe .google.com.pg .google.com.ph .google.com.pk .google.pl .google.pn .google.com.pr .google.ps .google.pt .google.com.py .google.com.qa .google.ro .google.ru .google.rw .google.com.sa .google.com.sb .google.sc .google.se .google.com.sg .google.sh .google.si .google.sk .google.com.sl .google.sn .google.so .google.sm .google.sr .google.st .google.com.sv .google.td .google.tg .google.co.th .google.com.tj .google.tk .google.tl .google.tm .google.tn .google.to .google.com.tr .google.tt .google.com.tw .google.co.tz .google.com.ua .google.co.ug .google.co.uk .google.com.uy .google.co.uz .google.com.vc .google.co.ve .google.vg .google.co.vi .google.com.vn .google.vu .google.ws .google.rs .google.co.za .google.co.zm .google.co.zw .google.cat

Google Analytics/AdWords caused issue discussed in https://stackoverflow.com/questions/34361383/google-adwords-csp-content-security-policy-img-src

[Drag13]

Please, forgive my intruding, but this issue is still actual, especially when we are speaking about google-ads.

If you want to have google ads and CSP, you have only two options:

• Specify all domains as @laukstein mentioned (that adds something like 1kb text)
• Or break security rules in favor of self https' that is far from ideal from a security perspective

So having the functionality to specify the country-specific domain (like https://my-domain.*) would be very helpful (and probably not only for google ads)

Could we expect some updates here?

[koto]

I can assure you Google doesn't own a google domain under all TLDs and I don't think there's a single organization that does.

[Drag13]

@koto I understand your point and it is totally reasoable. But don't you think that script-src: https://my-domain.*is much more secure than script-src: https: or just script-src:*?

If we take into consideration than CSP designed for security reasons, I think this might have a sense

[koto]

I actually don't think it is more secure, as attacking would only require having a few dollars to buy a domain (or finding a bug that lets you store files under one of google.TLD). That said, I'm not a huge believer in CSP domain whitelists in the first place, especially when whitelisting the domains you don't control yourself. I think in setups where you have 3rd party dependencies nonce-based CSPs should be preferred instead.

But that's not really about my opinion here. The issue is about adding a support for a feature that facilitates deployment of CSP policies by downgrading the security level (you already can maintain a specific domain whitelist, it's just hard). That always is a theoretical downgrade in security, so the decision to add it should not be taken lightly.

What people on the thread point out is that the downgrade is also real in practice (for google ads).

[Drag13]

require having a few dollars to buy a domain

This is a very good point I should say. I may contr-argue we still would have better security at least from script-kiddy and other automated and simple attacks.

But never-the-less, your argument is very strong.

[dveditz]

In practice this is only a problem with, and solution for, google services, right? Maybe Google customers can petition Google for a CSP-friendly version of these services, or follow the Google security team's advice to use strict-dynamic instead of host lists. Or switch to a CSP-friendly competitor and let market forces do the talking.

I cannot imagine any of the browser vendors implementing CSP agreeing to this feature.

[laukstein]

I agree with @dveditz . This is Google issue and not in spec. I feel bad for Google screaming loud on how to deliver the best UX and development while themselves ignoring its own recommendations.

I think this proposal is unsafe and should be canceled. Almost none company would register (or even be able to do it) its domain under all ccTLDs. CSP is for safety, and single missing TLD can lead to serious issues.

[nycnewman]

Instead of a wildcard, what about an explicit list of tlds in a short form, i.e.

.google.com|ad|ae|af|ag|ai|al|am|ao|ar|as|at... etc

We have a hosting provider that we've already had to push hard to get their CSP header extended to 2K bytes. When you use Google Ads, Hubspot ads, linked in, facebook (yes my marketing team does this), then CSP get very big very fast. I can't enable enforcement at the moment due to this issue.

[AndrewStoyan]

yep @nycnewman, you will end up with 431 status code or not using CSP

[laukstein]

.google.com|ad|ae|af|ag|ai|al|am|ao|ar|as|at... etc

@nycnewman, don't forget second-level domains and how it may complicate it. For example sub-domain me.mod.com with .uk, .mod.uk, etc.

[mazen160]

I don't know if this a common use-case, but regular expressions should be a better approach for customization.

/(google)(com|ad|ae|af|ag|ai|al|am|ao|ar|as|at)/

[KristianH]

What about to use an external trusted source of listed domains?

Here would be list of Google domains https://www.google.com/supported_domains

Something like img-src: source=https://www.google.com/supported_domains

[koto]

You already have a similar functionality, but you have to maintain that list (of supported domains) itself, and serialize it directly onto the CSP header.

What this thread exemplifies is that allowlists are hard to maintain for 3rd party dependencies, and would continue to be like this. Moving the maintenance burden for them from the application owner to the 3rd party does not make the problem fundamentally simpler, and introduces other issues, e.g.

• When should the supported_domains be fetched?
• It needs to be a blocking request, as it's for security, so how should websites stay performant?
• How to handle revocation?
• How to make sure we're not introducing a tracking vector to the 3rd party?

My suggestion is to move away from allowlist for 3rd party dependencies you wish to control via CSP. They are only deceivably simple.

[lukos]

My suggestion is to move away from allowlist for 3rd party dependencies you wish to control via CSP. They are only deceivably simple.

@koto Can you explain what you mean by this? Are you saying that CSP is not worth the hard work or are you saying not to use 3rd-party dependencies because they are too hard to whitelist?

CSP already has a size limit and it does make me uncomfortable making such a large CSP header for every response but this problem with Google affects us also.

[koto]

I am saying that CSP script-src URL whitelist approach is not a best fit to limit 3rd party dependencies your application loads. Use a nonce-based approach instead.

[MykolaiKorniat]

Are there any updates?

[h2oearth]

I have the feeling that the community sees this as an edge case :-(