現在のWebsocket RFCでは、Websocket クライアントが送信時にフレーム内のすべてのデータをマスクする必要があります（ただし、サーバーは必須ではありません）。プロトコルがこのように設計された理由は、フレームデータがクライアントとサーバーの間の悪意のあるサービス（プロキシなど）によって変更されるのを防ぐためです。ただし、マスキングキーはまだそのようなサービスで認識されています（各フレームの先頭でフレームごとに送信されます）。
フレームを次のポイントに渡す前に、そのようなサービスがキーを使用してコンテンツのマスクを解除、変更、および再マスクできると仮定するのは間違っていますか？私が間違っていない場合、これはどのようにして想定される脆弱性を修正しますか？
回答:
RFCのセクション10.3は、マスキングが必要な理由を正確に説明しています。これは、特定のハッキング手法に対する非常に具体的な対応です。それが対処しようとしている問題は、最も鋭いインターネットトランスポートセキュリティ関係者の一部が2010年の「Talking to Yourself for Fun and Profit for Fun and Profit」と呼ばれる論文で説明しています。
クライアントからサーバーへのマスキングは、プロキシがWebSocketsデータをキャッシュ可能なHTTPリクエストとして意図せずに処理するのを防ぐために、Websocketプロトコルによって使用されます。あなたがそれが愚かなプロキシにうろついているかどうかを議論することができます（そして私はそうだと思います）が、それが理由です。
wss://SSL / TLSを介したWebSocket とも呼ばれるマスキングは役に立ちません。可能な限りSSL / TLSを使用することをお勧めしますので、マスキングは限界的なユースケースをカバーすると合理的に結論付けることができます。