As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera.
Oh hey! That’s why I’ve been seeing lax and strict things on cookies on sites lately!
We’d definitely want a way to use different cookies, one lax and one strict for sure, different session types!!!
I does, though if you have a public WS API (and if you have native apps as clients, you have to) you must disable the origin check.
No you don’t, just specify an origin in the library you use, every native websocket client library I’ve touched yet (5 while I was testing) have an option to specify the origin. 
Hm, I used React Native with Phoenix Socket library (technically not a native ws lib) and didn’t see such an option, here are the ones the can be specified phoenix_socket/dist/socket.js at master · mspanc/phoenix_socket · GitHub maybe it would work as a key in params?
Anyway the way I see it is an origin that we can freely control can also be controlled by a malicious 3rd party so it doesn’t add much in terms of security.
You aren’t allowed to control the origin header from inside the web browser sandbox as per the standard, hence why a web browser javascript library doesn’t expose such an option. 
The origin header is to control web browser security, if you are in native code then you could easily just scrape a webpage to get a token (potentially even grabbing the web browsers cookie or whatever else) and then feed that in to the live websocket, so none of that security matters anyway for native code (hence why you should build a proper auth system if you need auth regardless, but the browser should be able to store that auth in a cookie backed by an origin as that is the way the standard was written).
The best explanation is here:
https://medium.com/coletiv-stories/using-websockets-with-cookie-based-authentication-7e4bb9262898
Exactly my point, hence why it should be stored in the cookie.
For example, for what JWT is designed for.
I’ve carefully read all the concerns about security (I agree with), BUT I think you are just considering scenarios in which the same Phoenix backend is both the authentication service AND the websocket endpoint.
I want to suggest you another scenario, for which the suggested workaround of using a csrf token from the Phoenix backend won’t be possible.
Let’s say we have these services:
A - login.somesite.com: Ruby on Rails (or whatever you prefer) backend that has the responsibility to Authenticate user (= to return a jwt token, in response to a login request, through a HttpOnly, secure, SameSite strict)
B - www.somesite.com: another (micro)service that renders tha app and manges the Business logics.
C - communications.somesite.com: the Phoenix (micro)service that handles WS Communications.
If you prefer, B & C might be the same service, no matter.
Service A sends a signed JWT HttpOnly cookie on domain “.somesite.com”, so that each services can exploit a decentralized authentication / verification, without the need of asking A (of course, that’s the way JWT has been designed for).
The wss protocol used to open a bidirectional channel, as you pointed out, allow us to send that jwt cookie to the C service (Phoenix) too, without the need to make the jwt accessible to the JS (it would open a way more dangerous security problem, if we woudn’t have that cookie “HttpOnly”).
Here, unfortunatly, comes the Phoenix backend with its design choices, that prevent us from reading that cookie (that wss protocol would let us send), making it useless.
I agree with the concerns that having a secure first design approach is in general a good choice, but in this case:
I would have prefered - in these cases - a “smart config” approach, if you care so much about CSWSH risk, where developers can - through an opt-in choice in server configuration - choose to have the cookie available in the connection endpoint.
What do you think about?
We can get access to the user_token natively by copying LiveView’s approach (CSRF):
# lib/web/endpoint.ex
@session_options [ ... ]
socket "/socket", Web.UserSocket, websocket: [connect_info: [{:session, @session_options}]]
// assets/app.js
let csrf_token = /* get via `csrf_meta_tag()` or `csrf_token_value()` */
let socket = new Socket("/socket", {params: {_csrf_token: csrf_token}});
# lib/web/channels/user_socket.ex
def connect(_params, socket, %{session: session}) do
if user_token = Map.get(session, "user_token") do
user = Account.get_user_by_session_token(user_token)
{:ok, assign(socket, :user, user)}
else
:error
end
end
SameSite looks available to browsers for quite some time. Does it change situation regarding the possibility of optionally using cookies for authentification in websockets? (even as web-specific option not available for possible custom transports)
Also, how could banning the user be implemented when using a token-based socket authentification? It looks to be problematic