35 ms·

I personally always thought that the CORS domain checking was needlessly and overly restrictive. I can understand entirely different top-level domains; definit

I personally always thought that the CORS domain checking was needlessly and overly restrictive. I can understand entirely different top-level domains; definitely 100% necessary. You start to lose me at different sub-domains for the same top-level domain. Do we really need to check api.example.com from app.example.com? Chances are good that they're both controlled by the same entity, so what's the problem? I'm out the door and around the corner when it gets down to the port number of the host. So now two requests that should resolve to the same machine need a CORS check? I think MS did right in having IE ignore the port in CORS domain checks. Not sure whether Edge does.

Manishearth 11y ago
> 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.
- terinjokes 11y ago
  Then request to add yourself to the public suffixes list.
  - Manishearth 11y ago
    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.
  - jessaustin 11y ago
    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?
e12e 11y ago
> Do we really need to check api.example.com from app.example.com? https://d3nb9u6x572n0.cloudfront.net https://d3nb9u6x572n0.cloudfront.net ?

Manishearth 11y ago

> 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.

terinjokes 11y ago
Then request to add yourself to the public suffixes list.
- Manishearth 11y ago
  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.
- jessaustin 11y ago
  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?

e12e 11y ago

> Do we really need to check api.example.com from app.example.com? https://d3nb9u6x572n0.cloudfront.net https://d3nb9u6x572n0.cloudfront.net ?