Google has quietly launched a CDN

Each cookie has a path set to it and browsers will obey it, this includes inter-domain paths and restrictions. If you want you can go even further and assign a cookie to a specific URI path so the cookie will only be issues to pages that fall under www.example.com/private/ for example if that's what the path is set too.

And the fact that big sites use it doesn't mean that they were "well written", Google mostly issues only tracking cookies for wildcard domains like .google.com as far as private cookies go they usually would be issued for each domain individually (play.google.com etc.). Issuing authentication cookies to wildcard domains and root paths isn't advisable even if some big sites do it doesn't mean you should take it as an example :)

P.S. I really hate "Google and Facebook are doing it" as an example, even if they are you most likely aren't either of them, not even close they have quite different considerations than you. Even when they do things which aren't best practice or common sense it doesn't mean that you should decide to take the same path, both Google and Facebook have plethora of ways to ensure account security including quite decent activity heuristics, they have many ways of detecting attacks such as XSS, and they have most likely a much better process of ensuring that vulnerable pages do not go live or do so quite rarely. Unless you can say the same then do not use them as an excuse, you do not need to issue cookies to wildcard domains and you can restrict them to certain paths, and you better do so because you do not have many other mitigating controls in place as the big players do.

You share quite a bit of things with your CDN quite often various API keys, as well as SSL certificates unless you do not serve your main content over SSL in the first place.

Most (I'm pretty sure all) CDN's give you the ability to set your own CORS policy if you see a CDN on cdn.example.com returns allow origin * then it means it's user did not set the CORS headers properly. Also the CDN can return allow allow and it still will not make a difference if you issue your cookies to the proper domain and path e.g. www.example.com/account if that's the domain and path there is no way a modern browser will attach that request to anything which doesn't sit on www.example.com and is located under /account.

If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is).

I cant discuss your whole comment because it's long and I'm on a phone.

"If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is)."

There is so much wrong about this paragraph. Who needs session theft in the scenario you provide..

If you have 100s of XSS on your site and a bad CORs policy there is a lot an attacker can do... Data exfiltration is very easy if you can execute js and so are things like XSRF.

A correct path and domain setting for cookies is important but web security is a lot harder than your acting like it is..