Documentation should note that package ignores protection against untrusted client

[propertyscott]

The client does not mask sent messages or verify the the Sec-WebSocket-Accept header. Because these features are required by the protocol and related to security, the documentation should note the omission of the features.

It's unlikely that the package will be used in an application running untrusted code, but the package might be used in a websocket proxy that forwards requests from untrusted code.

[nhooyr]

Will add masking ASAP - https://tools.ietf.org/html/rfc6455#section-10.3

Wasn't aware it was still a real issue on the modern internet and I didn't expect anyone to be running untrusted code with this library.

Will generate a unique Sec-WebSocket-Key as well. Based on https://stackoverflow.com/a/37074398/4283659 I decided not to implement it but it looks like there is a strong reason to do so: https://stackoverflow.com/a/37074398/4283659

[propertyscott]

The problem scenario is a websocket proxy server that uses this package as a websocket client.

Possible attack: The missing features give code from origin evil.com significant control over data sent to good.com's backend servers. The code from evil.com uses this control to exploit bugs at good.com and make cross origin requests.

[nhooyr]

Possible attack: The missing features give code from origin evil.com significant control over data sent to good.com's backend servers. The code from evil.com uses this control to exploit bugs at good.com and make cross origin requests.

By default no cross origin requests are allowed. See the docs on Accept.

[nhooyr]

Have tagged a new release with WebSocket masking and Sec-WebSocket-Accept verification. Should be good now.

[nhooyr]

Ah I think I misinterpreted your comment.

Possible attack: The missing features give code from origin evil.com significant control over data sent to good.com's backend servers. The code from evil.com uses this control to exploit bugs at good.com and make cross origin requests.

There is no attack vector there as far as I can tell and WebSocket masking and Sec-WebSocket-Accept do not affect a WebSocket proxy.

[propertyscott]

Thank you for fixing the issue.

By default no cross origin requests are allowed

If the proxy server developer assumes that the backend server will check the origin, then the developer might disable the origin check for Accept.

WebSocket masking and Sec-WebSocket-Accept do not affect a WebSocket proxy.

These features do affect a proxy server that creates websocket.Conn's and pumps messages between them. I don't think that's the right way to write a WebSocket proxy server, but there are a few that do this.