No, since this is an intentional design decision. WebSockets are not restrained by the same-origin policy, so using cookies could actually leave folks vulnerable to the xss you are wanting to avoid. We also don’t support them because channels are transport agnostic, and not all transports would support cookies. The recommended approach is to use Phoenix.Token to sign data into a token, then verify it on the server as a replacement for cookies. This works across any transport and client.

Apologies for the zombie thread, but I’m not sure I understand the rationale for not providing the option of reading cookies in the socket connect handshake.

It’s my understanding that a considerably safer method for storing and sending an auth token is via a HttpOnly cookie (provided you have CORS policies to prevent CSRF / CSWSH). With this, JS cannot access the tokens, and the browser does the storing / sending.

I understand the CSWSH concern due to lack of default CORS policy, but that sounds more like a strong warning to developers to check the origin, rather than just not supporting it at all.

On the flip side, we could pass a Phoenix.Token / JWT as a socket connection param, but the problem is that you have to get it to the socket constructor somehow. A <meta /> tag, localStorage, window.__INITIAL_STATE__, etc., are all easily accessible via JS (and therefore in a XSS attack).

So some clarification on this would be helpful.

This article explains the issue: Cross-Site WebSocket Hijacking (CSWSH)

If website A opens up a websocket to website B, then the browser will send all cookies and authentication headers that belong to website B, even though the request was made from A.

This is orders of magnitude worse than CSRF. CSRF is a blind attack, you can trigger it but you can’t read the result. On the other hand, CSWSH gives the attacker full control of the socket, you can read from the socket, write to the socket, and perform any other operation available through the socket.

Note Phoenix does validate the Origin by default. Still I don’t think we should allow cookies to be read. Messing this up opens up a very big vulnerability and Phoenix is correct in making it double sure it can’t happen. All of the information you want to pass as a cookie can be passed in a safer way.

If your site is exposed to XSS, then it is game over anyway, because with XSS you can directly open up a websocket connection without relying on CSWSH. So you shouldn’t worry about storing those in meta or local storage since XSS allows you to cause much more damage than what the token is meant to prevent.