3 ms·

> Threat > Attackers may use the API to by-pass third parties' CORS policies. > Mitigation > We could forbid the API from being used for TCP with the well kn

> Threat > Attackers may use the API to by-pass third parties' CORS policies. > Mitigation > We could forbid the API from being used for TCP with the well known HTTPS port, whenever the destination host supports CORS. I'm really curious about the implicit ethics here. There's this idea that the web should be able to do everything that native apps can, an idea that I'm inclined to agree with. One thing that native apps can of course do is to bypass third parties' CORS policies. And there are may legitimate use cases for that, like feed readers for example. Right now, if you want a feed readers as a web app, you need a backend, to be able to request feeds (and homepages, for autodiscovery). For a native app, you could do that all client side.

mr90210 4y ago
You’ve got a point, however almost every native app out there that constantly interact with a web api is likely written with web technologies and shipped with Chromium / Nodejs.
olalonde 4y ago
I also don't get it. The whole reason for CORS is "Resource Sharing" (e.g. indirectly using resources like cookies belonging to another domain). With direct sockets, no shared resource is being accessed, all the browser does is open a TCP connection (e.g. no cookie accessed or sent anywhere). I can understand that TCP connections could be abused by some websites (e.g. using your browser for spamming, accessing unsecured local services, etc.) but this can be solved with a permission style popup just like with the geolocation or webcam APIs.
- Timon3 4y ago
  I'm pretty sure "Resource Sharing" is about resources on a server being loaded from other origins, not about sharing client-side information. This is a client-side restriction. By offering an alternative you ship a workaround for CORS, effectively disabling it.
  - olalonde 4y ago
    If that's the case, what does it protect against? Reducing server load? This has always been trivial to bypass by proxying requests through a server. With a direct socket it would be the same except you wouldn't require a proxy server.
    - Timon3 4y ago
      Yes, the way you're stating it is fully correct. It is trivial to circumvent, but it would be so in your scenario too - sharing cookies is easy to implement in a proxy server. Still, for a simple website it's a big hurdle, since it forces you to build a proxy server.

mr90210 4y ago

You’ve got a point, however almost every native app out there that constantly interact with a web api is likely written with web technologies and shipped with Chromium / Nodejs.

olalonde 4y ago

I also don't get it. The whole reason for CORS is "Resource Sharing" (e.g. indirectly using resources like cookies belonging to another domain). With direct sockets, no shared resource is being accessed, all the browser does is open a TCP connection (e.g. no cookie accessed or sent anywhere). I can understand that TCP connections could be abused by some websites (e.g. using your browser for spamming, accessing unsecured local services, etc.) but this can be solved with a permission style popup just like with the geolocation or webcam APIs.

Timon3 4y ago
I'm pretty sure "Resource Sharing" is about resources on a server being loaded from other origins, not about sharing client-side information. This is a client-side restriction. By offering an alternative you ship a workaround for CORS, effectively disabling it.
- olalonde 4y ago
  If that's the case, what does it protect against? Reducing server load? This has always been trivial to bypass by proxying requests through a server. With a direct socket it would be the same except you wouldn't require a proxy server.
  - Timon3 4y ago
    Yes, the way you're stating it is fully correct. It is trivial to circumvent, but it would be so in your scenario too - sharing cookies is easy to implement in a proxy server. Still, for a simple website it's a big hurdle, since it forces you to build a proxy server.