WebSocket セキュリティにはさまざまな側面があります。
あなたが引用したウィキペディアの抜粋は、WebSocketクライアントからサーバーデータへのマスキングについて言及しています。これは、不正な仲介者 (プロキシやキャッシュなど) が誤って WebSocket トラフィックを通常の HTTP トラフィックとして解釈するのを防ぐためです。ここでの危険は、WebSockets プロトコルを使用してキャッシングの仲介者を汚染する可能性があることです。ただし、これは純粋に理論上の懸念事項であり、Mozilla と Opera が WebSocket プロトコルの Hixie および初期の HyBi バージョンの出荷に消極的であったことは十分な懸念事項であったことに注意してください。そこで IETF は、この問題に対処するために、クライアントからサーバーへのデータ マスキングを追加することを決定しました。
余談ですが、IETF は WebSocket プロトコル (IETF 6455) を担当し、W3C は HTML5 WebSocket API (Javascript オブジェクト、メソッド、およびイベント) を担当しています。
WebSocket セキュリティのもう 1 つの側面は、クロスオリジン セキュリティです。W3C WebSocket API 仕様から引用した 2 番目のスニピットは、クロスオリジン セキュリティに関連しています。WebSockets はクロスオリジン接続 (HTML ページが提供された別のホストへの) をサポートします。この警告は、通常の HTTP クロスオリジン プロシージャが WebSocket に使用されていた場合、これは巨大なセキュリティ ホールを開くことになります。ただし、WebSocket の手順は、まさにこの理由で異なります。たとえば、WebSocket ハンドシェイクと応答は、WebSocket 接続をサポートしていない HTTP サーバーに対して WebSocket 接続を確立できないように設計されています。サーバーは、WebSocket 固有の方法でキーに署名/ハッシュし、これをハンドシェイク応答で返す必要があります。2 番目の部分は、ブラウザーがハンドシェイクの一部として Origin ヘッダーを送信する必要があることです (これは、HTML/Javascript が最初にどこから読み込まれたかを示します)。これにより、サーバーはWebSocket 接続の開始を許可するドメインを選択できます。
最後に、暗号化されていない (ws://) と暗号化されている (wss://) という 2 つの WebSocket 接続モードがあります。暗号化モードでは、TLS/SSL 暗号化を使用して、サーバーとの間で送受信されるすべてのデータ (最初のハンドシェイクと応答を含む) を暗号化します。これは、HTTPS 接続に使用されるのと同じ暗号化メカニズムです (ブラウザーで同じ暗号化エンジンを使用します)。これにより、第三者が転送中のデータを詮索することを防ぎます。
実際に知っておく価値のある WebSocket プロトコルのバージョンは 2 つだけです。
Hixie76 : このバージョンのプロトコルは、クロスオリジン セキュリティとヘッダー ハッシュ/署名を追加しました。ただし、プロトコルの設計方法が原因で、既存の Web サーバーにサポートを追加することは困難です。これは、iOS で現在サポートされているバージョンです (うまくいけば、iOS 6 は最終的に IETF 6455 に更新されます)。
IETF 6455 : これは、昨年 11 月 (2011 年 11 月) に IETF によって標準化された WebSocket プロトコルのバージョンです。これは、IETF HyBi ワーキング グループによる作業の集大成でした (それに至るまでのプロトコルの反復には、HyBi XX というラベルが付けられていました)。これは、現在のバージョンの Chrome と Firefox でサポートされているバージョンであり、IE 10 とまもなく Opera でサポートされるバージョンでもあります。