Cross-Site WebSocket Hijacking (CSWH) happens when an endpoint exposing a WebSocket is not guarded against Cross-Site Request Forgery (CSRF), e.g., it merely checks the cookies that come with the request to authenticate the client. This is particularly worrisome since, unlike regular CSRF, WebSockets are not subject to the Same-Origin Policy (SOP). In the case of Websockets, an attacker can only initiate a blind action on behalf of the authenticated user; however, in the case of a CSWH, the attacker can gain full access (full-duplex communication) on the WebSocket channel.
The impact depends on how the web application uses the WebSocket. For example, it could be the vector employed by the web application to notify some minor events, or it could be used as a unified way to issue sensitive commands to the backend.
Depending on the scenario, there are two effective ways to prevent CSWH exposure:
The usual CSRF prevention may be implemented for the endpoint that serves the WebSocket (e.g., introducing a CSRF token);
The WebSocket server may be instructed to only accept requests originating from an allow list of domains.
Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality.