From where does WebSocket requests comes from, that SOP cann't block attacks related to it ?
Same-origin policy considers all of these origins to be different:
http://example.com https://example.com ws://example.com wss://example.com
So if browsers were to apply SOP rules to WebSockets, if a page at
https://example.com tried to connect to a WebSocket at
wss://example.com it would fail.
In theory WebSockets could have been designed to use CORS headers during the initial HTTP handshake, but these two technologies were developed at roughly the same time.
Consider a case where a user browses a page at evil.com, and scripting in the page served by evil.com attempts to make a cross-site websockets request to bank.com in an attempt to access the user's sensitive banking information.
The websockets connection begins with a handshake to bank.com using https protocol. Because SOP does not apply to websockets, the scripting in the page served by evil.com will be able to access the response headers of the https handshake from bank.com, and send these response headers back to evil.com - but these are unlikely to contain any sensitive information. After the https handshake, the connection upgrades to
wss protocol. If bank.com does not support ws or wss protocol, then the connection will fail at that point. So, websockets cannot be used (abused) in the same way that XHR or Ajax can be used (abused) to attempt to access sensitive cross-site information by making standard https requests across sites.
If bank.com does support websockets protocol, then the onus is on bank.com to prevent unauthorized cross-site requests. In the websockets request to bank.com, the browser will send an
origin header containing the origin of the page making the request (evil.com), and it is up to bank.com to validate the request based on the origin.