開始時のハンドシェイクでのWebSocket認証は十分ですか？
TLSが使用され、標準のHTTPメカニズムを使用してセッションIDがネゴシエートされたとします。 WebSocketの開始ハンドシェイクでは、このセッションIDもHTTPヘッダーで転送されます。
セッションIDが無効な場合、WebSocketの開始ハンドシェイクが実行されないとします。
これらのメッセージに対してそれ以上の認証が実行されない場合でも、その接続を使用する後続のすべてのWebSocketメッセージのセキュリティは保証されますか？
ここに攻撃シナリオはありますか？
WebSocketは、最初にHTTPハンドシェイクを行い、次にメッセージベースの通信を確立することで機能します。すべてが単一のTCP=接続内で行われ、wss://の場合は単一のTLS接続内で行われます。最初にこの接続を認証します（たとえば、初期HTTP内でセッションCookieを送信してハンドシェイク）は、最初にSSHセッションのみを認証するか、最初に通常のHTTP/HTTPSリクエストのみを認証し、送信されたリクエストのすべてのバイトを再度認証しないことに似ています。
もちろん、最初のこの単一の認証は、次のデータが何らかの方法で操作できない場合にのみ十分です。あなたの例ではTLSを使用するwss://が使用されており、これにより、途中のアクティブな男性による操作からデータが保護されます。
しかし、たとえば攻撃者が（たとえばXSSを使用して）接続のエンドポイントを侵害した場合、攻撃者は既に認証されたWebSocketを介して自分のメッセージを送信できる可能性があります。攻撃者が確立されたWebSocket内でメッセージを送信できる場合、攻撃者は新しいWebSocketも確立できる可能性があります。また、これらがセッションCookieで認証される場合、新しいWebSocketを確立するときに、ブラウザのみが自動的にCookieを含めます。つまり、暗黙的に認証されます。したがって、これに対する緩和策は、すべてのWebSocketメッセージを認証することではなく、攻撃者が最初にXSSなどを使用してWebアプリケーションのクライアント側を危険にさらすことができないようにすることです。