So it looks like there is _yet another_ Web standard that is already tackling all this, and in fact they already did the threat assessment: https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md
> 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.
The whole point of CORS is that you cannot leak any information by default. By allowing connection to hosts that don't support CORS you are effectively doing the opposite.
Yeah. I want to spend some time thinking about the threat model here, because I would like to come up with my own solutions and see how they mesh with the current CORS design, etc.
This has been very useful, though - I'm glad I posted about all this, because I don't think I would have found that Direct Sockets thing otherwise.
So it looks like there is _yet another_ Web standard that is already tackling all this, and in fact they already did the threat assessment: https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md
Their threat assessment is very _interesting_.
> 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.
The whole point of CORS is that you cannot leak any information by default. By allowing connection to hosts that don't support CORS you are effectively doing the opposite.
Yeah. I want to spend some time thinking about the threat model here, because I would like to come up with my own solutions and see how they mesh with the current CORS design, etc.
This has been very useful, though - I'm glad I posted about all this, because I don't think I would have found that Direct Sockets thing otherwise.