> Do we really need to check api.example.com from app.example.com?
Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.
So rely on proactive work by various SaaS vendors/other domain owners to preserve security for some of their clients, rather than relying on well-defined action from the owners of a particular service to ensure that said service works at all? Seems like we're "failing open" with the policy you suggest?
That's not yet used by all browsers. And it's a bit more restrictive than necessary, since the base domain is supposed to not be a website at all (and loses the ability to do some things with cookies iirc). That's not always the case. co.uk doesn't need to set cookies, but blogspot.com does (and is a website), so .blogspot.com can't be an eTLD.
Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.