1. 序論
開発者は、自身のページのコンテキストに読み込まれるリソースと、 そのページがリクエストを行えるエンドポイントを制御したいと考えている。この制御は、 ユーザーのデータがユーザーエージェントを通じて流れる方法を制限すること(データ流出攻撃の緩和)や、 サイトのアーキテクチャと依存関係を確実に制御することを含む、いくつかの目的に必要である。
Content Security Policy はこの必要性の一部に対処しているが、最も重要なユースケースに必要なものよりも 細粒度な方法で行っており、また CSP がデプロイに用いられる他の保護によって複雑化した構文と文法を持つ。 [CSP]
`Connection-Allowlist`
は CSP から一歩引き、ページが Fetch および他の Web プラットフォーム API(WebRTC、Web
Transport、FedCM、Web Payments、DNS Prefetch など)を通じて開始できる明示的なリクエストを、
単純明快かつ包括的であることを目指す方法で制御するという、単一のユースケースに焦点を当てる。
注: '\' による行折り返しは RFC 8792 に従う
Connection-Allowlist: (response-origin "https://cdn.example" "https://*.example.:tld" \
"https://api.example:*"); report-to=ReportingAPIEndpoint
ユーザーがナビゲートした文書とともに配信されるこのヘッダーは、
その文書を、リストで指定された URL パターン
[URLPATTERN]
に一致するエンドポイント、すなわちその文書が配信されたオリジン、
https://cdn.example、DNS ラベルの末尾から 2 番目が
example である任意のホストの任意のサブドメイン、
任意のポート上の https://api.example、などに対するリクエストと接続だけを
許可するよう制限する。
許可リストに一致しないエンドポイントへの接続の試みはブロックされ、
report-to パラメーターで指定された Reporting API
[REPORTING] endpoint
(別個の Reporting-Endpoints ヘッダーを通じて定義される)を介して報告される。
1.1. 脅威モデル
この提案は意図的に小さく、クライアントサイド攻撃および/または誤設定の、 具体的だが有用なニッチを対象としている:
-
文書およびワーカー向けのポリシーは、サーバーによって HTTP レスポンスヘッダーとして表明される。 これは、レスポンスヘッダーを操作できる攻撃者は引き続きスコープ外であることを意味する。
-
文書(またはワーカー)の表明されたポリシーは、_その_ コンテキストによって開始されたリクエストのみを支配する。 フレーム化された文書が別個のポリシーを表明するなら、それはそれでよい(ただし、このポリシーは ローカルスキーム(
data:、about:など)を介して作成されたコンテキストにも適用されるという注意点がある)。 これは、新しい文書/ワーカーコンテキストを作成する際に HTML によって処理される、コンテキストの policy container の他の構成要素と同様である。 -
この提案が防御しようとする脅威は、接続および/またはリクエストである。データ流出防御として有効であるためには、 接続が行われる前に接続をブロックしなければならない。
-
その他の優れた Web プラットフォーム API の意図しない影響として利用可能なサイドチャネルは非常に多い。 この提案はそれらに対処しようとはせず、ページのためにユーザーエージェントによって明示的に開始される リクエストまたは接続のみに焦点を当てる。これには明らかに、
fetch()およびXMLHttpRequestの明確なケースに加え、 一般的なリソースリクエストも含まれる。また、より明示的には「リクエスト」ではないチャネルを通じて確立される ネットワーク接続も含まれる。すなわち、Web Install API を通じてフェッチされるマニフェスト、WebRTC による TURN/STUN サーバーへの接続、Web Transport チャネル、DNS プリフェッチ、ナビゲーションなどである。 これらはすべてスコープ内であり、一方でメモリや CPU 消費、ソケット枯渇、一般的な XSLeaks のような より難解なチャネルはスコープ外である。 -
この提案は通信チャネルのみを扱う。コンテンツ注入やクロスサイトスクリプティングのような脅威を 防止する(あるいは実質的に緩和する)ことを目的としていない。そのような攻撃の影響を、 ポリシーが適用されている_それらの特定のページ_でのみ制約できるにすぎず、 ページの防御における 1 つの層としてのみ考えるべきである。それ自体では十分ではない。
-
オープンリダイレクトのようなサーバーサイド脅威の一部に対して防御を試みることは魅力的である。 クライアントを離れたデータは基本的にサーバーの制御下に入るため、効果的な方法でそうすることには苦労するだろう。 とはいえ、リダイレクトレスポンスを通じて他のサーバーへの接続を作成するというサーバーの決定に、 クライアントが直接協力するかどうかを開発者が選択できるようにするのは合理的に思われる。 今後より細かな粒度が必要になった場合に拡張の余地を残しつつ、2 つの選択肢を提供する。 デフォルトでは、宛先に関係なくリダイレクトレスポンスはブロックされる。開発者は、ヘッダーに パラメーターを設定することで、すべてのリダイレクトレスポンスを許可することを選択できる。 詳細は § 5.5 リダイレクト を参照。
-
同様に、WebRTC 接続は、動的なエンドポイント発見やピアツーピア接続を伴うことが多いため、 URL パターンによって制約することが難しい。開発者が WebRTC 接続を完全に許可するかブロックするかを 選択できるように、グローバルトグルを提供する。詳細は § 5.6 WebRTC を参照。
1.2. Content Security Policy との重複
この提案は、特定のコンテキスト内でのリソース利用に対する制限についての Content Security Policy のアプローチ、 特に fetch directives と多くの共通点を持つ。それでもなお、 いくつかの理由から検討する価値があるように思われる:
-
CSP のモデルは細かすぎる: 機密性の高いコンテキストからデータが流出するリスクを緩和したい開発者は、 リクエストの発行や接続の確立が可能な方法を網羅的にカバーする保護を必要とする。 CSP による、リクエストを個別に制御できる種類へ分類する方法は、この問題に取り組む方法としては誤っている。 Web フォントのリクエストを通じたデータ漏洩は、画像やスクリプトのリクエストを通じたデータ漏洩と同じくらい悪いからである。 これらのリクエスト種別を区別すると、単に無関係な疑問によって、合理的な防御を設計する過程が複雑化する。
-
CSP の構文は十分に粒度が細かくない: CSP がサポートする
host-source文法は、レスポンスとともに配信される ヘッダーを本当に冗長なものにする。別個のポリシーは、URLPattern 構文へ移行する機会を提供する。 これは、より現代的で、柔軟で、標準化された照合構文を提供することで、CSP のアプローチに関して人々が提起してきた いくつかの不満を解決するだろう。 -
CSP のカバレッジは不完全である: CSP は Fetch を通る HTTP リクエストをうまくカバーしているが、 Web プラットフォーム API が接続の確立を可能にする無数の方法を網羅的にカバーしているわけではない。 DNS プリフェッチと WebRTC は取りかかるべき良い例だが、CSP の脅威モデルにどのように適合するのかに まさに苦慮してきたものは他にも多い。狭い焦点と開発者への明示的な約束を持つ新しいポリシーを作成することで、 これらの議論には防御可能な答えと、仕様作成者への明確な権限が与えられるだろう。
2. 接続許可リスト
Connection Allowlist は、特定のコンテキストが接続を許可される URL patterns の集合を表す。 これは、以下の items を持つ struct である:
-
allowlist。これは list の URL patterns である。 別途指定されない限り、空のリストである。
-
reporting endpoint。これは
nullまたは Reporting API endpoint のいずれかである。別途指定されない限りnullである。 -
disposition。これは enforce または report のいずれかである。
-
redirects。これは allow または block のいずれかである。別途指定されない限り、 block である。
-
webrtc。これは allow または block のいずれかである。別途指定されない限り、 block である。
3. Connection Allowlist ヘッダー
Connection-Allowlist レスポンス header は、 コンテキストが接続を許可されるエンドポイントの集合を定義する、シリアライズされた URL パターン文字列のリストを含む。 この許可リストは特定のコンテキストに対して強制され、表明されたパターンに一致しない発信接続をブロックする。 Connection-Allowlist-Report-Only レスポンス header は report-only 変種であり、同じ方法で構文解析されるが、 発信接続をブロックせずに違反レポートのみを送信する。
これらの Connection Allowlist ヘッダーは structured headers であり、その値は list の inner lists である。サーバーは任意の数の項目を含むリストを配信してよいが、 最初の項目だけが使用される。リスト内の追加の項目はすべて無視される。
inner list には、strings
としてシリアライズされた URL Patterns、または
token
response-origin のいずれかを含めることができる。
これは response の URL の
origin に一致するパターンを表す。予期しない値は無視される。
inner list は任意の parameters を持ってよい:
-
report-toパラメーターの値は、 Reporting API endpoint [REPORTING] を表す token として構文解析される。 -
redirectsパラメーターの値は、 token として構文解析される。存在する場合、それは許可リストの redirects を設定するために使用される。 値が tokenblockである場合は block に設定され、 それ以外の場合は allow に設定される。 -
webrtcパラメーターの値は、 token として構文解析される。存在する場合、それは許可リストの webrtc を設定するために使用される。 値が tokenblockである場合は block に設定され、 それ以外の場合は allow に設定される。
その他すべてのパラメーターは無視される。
3.1. 構文解析
-
allowlists を空の list とする。
-
header を、response の header list から、 `
Connection-Allowlist` という名前の structured field value を取得した結果とし、 それを list として扱う。 -
header、response の URL、および enforce が与えられたものとして、 Parse a Connection Allowlist header する。結果が
nullでない場合、それを allowlists に insert する。 -
header を、response の header list から、 `
Connection-Allowlist-Report-Only` という名前の structured field value を取得した結果とし、 それを list として扱う。 -
header、response の URL、および report が与えられたものとして、 Parse a Connection Allowlist header する。結果が
nullでない場合、それを allowlists に insert する。 -
allowlists を返す。
-
list の size が 0 である場合、
nullを返す。 -
list[0] が inner list でない場合、
nullを返す。 -
allowlist を、その disposition が disposition である Connection Allowlist とする。
-
list[0] 内の各 item について For each:
-
serialized pattern を
nullとする。 -
item が token
response-originである場合:-
serialized pattern を、response-url の origin の ASCII serialization に設定する。
-
-
item が string である場合、 serialized pattern を item に設定する。
-
serialized pattern が
nullである場合、 continue する。 -
URL pattern を、
nullを基底 URL として serialized pattern が与えられたものとして build a URL pattern from an HTTP structured field value を実行した結果とする。このステップがエラーを投げる場合、 continue する。
-
-
list[0] の parameters 内の各 key → value について For each:
-
key が
report-toであり、value が token である場合、allowlist の reporting endpoint を value に設定する。
-
-
allowlist を返す。
注: 構文解析アルゴリズムでは、 無効な入力をすべて飛ばしている。もっと厳格な構文解析を行うことも十分あり得るが、 それは将来の柔軟性を制限する可能性が高い。
3.2. 照合
確立される接続の種類によっては、処理対象となる request がある場合もあれば、
URL
しかない場合、あるいはそれより少ない情報しかない場合もある。
たとえば dns-prefetch は、
ホストに対してのみ照合できる。以下のアルゴリズムは、これらのシナリオで接続許可リストのチェックがどのように機能するかを規定する:
-
connection allowlist の allowlist 内の各 pattern について For each:
-
input を新しい
URLPatternInitdictionary とし、そのhostnameを pattern の hostname component に設定する。 -
host-only pattern を、 input、基底 URL としての
null、および options としての空の map が与えられたものとして creating a URL pattern した結果とする。 -
synthetic url を、 "https://" と host を連結したものを URL として parsing した結果とする。
-
host-only pattern と synthetic url が与えられたものとして URL pattern matching が
nullを返さない場合、success を返す。
-
-
failure を返す。
注: hostname component だけを持つ新しいパターンを作成し、 host 用の URL を合成することで、 任意のプロトコル、任意のポート、任意のパスなどでそのホストへのリクエストを許可し得るパターンが 許可リスト内に_少しでも_存在すれば、一致を返すことができる。
-
connection allowlists 内の各 connection allowlist について For each:
-
url、environment、および connection allowlist が与えられたものとして Report a violation する。
-
connection allowlist の disposition が enforce である場合、 blocked を返す。
-
allowed を返す。
-
allowlists を、request の policy container の connection allowlists とする。
-
allowlists 内の各 allowlist について For each:
-
request の URL list の size が 1 より大きい場合:
-
request の url、request の client、および allowlist が 与えられたものとして Report a violation する。
注: リダイレクトが ブロックされる場合、リダイレクト先について必要以上の情報を漏らすことを避けるため、 意図的に request の url を報告し、その current url は報告しない。
-
allowlist の disposition が enforce である場合、 blocked を返す。
-
Continue する。
-
request の url、request の client、および allowlist が 与えられたものとして Report a violation する。
-
allowlist の disposition が enforce である場合、 blocked を返す。
-
-
allowed を返す。
-
connection allowlists 内の各 connection allowlist について For each:
-
host が connection allowlist に host-matches する場合、 continue する。
-
host、environment、および connection allowlist が与えられたものとして Report a violation する。
-
connection allowlist の disposition が enforce である場合、 blocked を返す。
-
-
allowed を返す。
-
allowlists を、environment の policy container の connection allowlists とする。
-
allowlists 内の各 allowlist について For each:
-
"
webrtc"、environment、および allowlist が与えられたものとして Report a violation する。 -
allowlist の disposition が enforce である場合、 blocked を返す。
-
allowed を返す。
3.3. 報告
他のポリシー機構と同様に、Connection Allowlists は、許可リストヘッダーで指定された Reporting API エンドポイントへ各違反を報告する。違反は、次の dictionary 型によって表される:
enum {ConnectionAllowlistDisposition ,"enforce" };"report" dictionary :ConnectionAllowlistViolationReport ReportBody {USVString ;url USVString ;connection sequence <DOMString >;allowlist ConnectionAllowlistDisposition ; };disposition
ConnectionAllowlistViolationReport
の
connection
は、許可リストに違反した接続の、シリアライズされた
URL
である。
ConnectionAllowlistViolationReport
の
allowlist
は、違反された
allowlist である。
ConnectionAllowlistViolationReport
の
disposition
は、allowlist
の
disposition である。
webrtc" (resource URL)、environment (environment)、および
connection
allowlist (allowlist) が与えられたとき、
report a violation するには、次を行う:
-
allowlist の reporting endpoint が
nullである場合、返す。 -
violation を、新しい
ConnectionAllowlistViolationReportとし、次のように初期化する:
url-
environment の creation URL を、 stripped for use in reports したもの。
connection-
resource URL が URL である場合、 resource URL を stripped for use in reports したもの。
それ以外の場合、resource URL。
allowlist-
allowlist の allowlist 内の各パターンをシリアライズした結果を含む新しいリスト
disposition-
allowlist の disposition。
-
environment をコンテキストとして、"
connection-allowlist" を type として、allowlist の reporting endpoint を destination として、そして violation を data として与え、 Generate and queue a report する。
4. モンキーパッチ
4.1. Fetch との統合
同じ目的を果たす他のチェックと並んで、Fetch § 4.1 Main fetch に ブロッキングチェックを追加することで、requests を扱う:
-
bad port により request がブロックされるべきか、mixed content として fetching request がブロックされるべきか、Content Security Policy により request がブロックされるべきか、 should request be blocked by Connection Allowlists、 または Integrity Policy Policy により request がブロックされるべきかが blocked を返す場合、response を network error に設定する。
Fetch は、requests に基づかない API のために接続を確立する際に使用される、 より低レベルのアルゴリズムも定義している。DNS プリフェッチ、Web Transport などを扱うため、resolve an origin と obtain a connection にフックする:
- should host be blocked by Connection Allowlists が、origin の host、environment、および allowlists に対して実行されたときに blocked を返す場合、 failure を返す。
- should url be blocked by Connection Allowlists が、url、environment、および allowlists に対して実行されたときに blocked を返す場合、 failure を返す。
Fetch への変更では、 使用すべき許可リストと、報告に使用すべきコンテキストを識別するために、 低レベルアルゴリズムの呼び出し箇所へ追加情報を渡す必要がある。 代わりに、それらの呼び出し箇所自体にチェックを実行させた方がよいかもしれない。 私の感覚では、ロジックを集中化する方が成功しやすいが、個別対応のアプローチを取る方が単純かもしれない。
4.2. HTML との統合
上記を HTML に統合するために、policy container struct に、 connection allowlists の list を含む新しい connection allowlists item を追加する。 これは、create a policy container from a fetch response アルゴリズムにステップを追加することで設定される:
-
response と result で Integrity-Policy ヘッダーを構文解析する。
- result の connection allowlists を、 response が与えられたものとして parsing a response’s Connection Allowlists した結果に設定する。
-
result を返す。
注: Early hint 統合には追加の変更は不要である。 early response の policy container は、early hint links をフェッチする際に既に使用されているためである。
4.3. WebRTC との統合
WebRTC 接続を制約するために、[webrtc] は、候補が administratively prohibited であるかどうかを判断する際に、 should WebRTC be blocked by Connection Allowlists アルゴリズムを呼び出すことができる。
4.4. Service Workers との統合
サービスワーカー自身の policy container を適用するという既定の挙動に加えて、
service workers は、WindowClient
API を使用してナビゲーションを呼び出す際に、自身の接続許可リストを適用する必要がある。
navigate()
および openWindow(url)
アルゴリズムはいずれも次のようにパッチされなければならない:
-
should url be
blocked by Connection Allowlists が、url、
this の
relevant settings object、および
this
の
relevant settings object の
policy container の connection allowlists に対して実行されたときに
blocked を返す場合、
"SecurityError"DOMExceptionで拒否された promise を返す。
navigate()
は現在の文書をナビゲーションの sourceDocument として渡す。これは少し見落としのように思われる。
議論を参照。
5. セキュリティおよびプライバシーの考慮事項
5.1. 同一オリジンコンテキスト
§ 1.1 脅威モデル で説明した脅威モデルは意図的に狭く、
開発者はここで説明される許可リスト機構をどのように自身の防御へ階層化するかを
慎重に検討する必要がある。最も重要な点として、この機構はコンテキスト固有であり、
オリジン全体に及ぶものではない。これにより、スクリプト実行権限を持つ攻撃者が、
より制限の低い同一オリジンのコンテキストを見つけて、あるコンテキストの許可リストを
回避する広範な余地が残る。HTML の policy container との統合は、
それらの可能性の一部に対処するが、他にも存在する可能性が高い。たとえば攻撃者は、
フレームツリーを上方向にたどって制限のより緩い親に到達したり、opener 関係を保持する
新しいウィンドウを window.open() で開いたりできるかもしれない。
したがって、文書のオリジンを(response-origin
によって、または明示的に)
許可リスト化することは、それ自体では完全な解決策ではない。
開発者が、許可リスト化されたコンテキストを通常のオリジンから切り離して sandbox 化することで、
このリスクを回避できるシナリオもある。これには
sandbox
属性や Content Security Policy の
sandbox
ディレクティブを使用できる。そのような場合、同一オリジンの文書は存在せず、境界を維持しやすくなる。
開発者が依存関係の 許可リストをある程度制御できるようにすることも理想的である。 required document policy や [csp-embedded-enforcement]] のようなものに根ざした オプトイン機構を探ると役に立つかもしれない。[WICG/connection-allowlists Issue #1]
5.2. Service Workers
Service Workers は、他の同一オリジンコンテキストと同様に、 許可リストを巡る事情を複雑にする。Service Workers は、それらが管理する各文書とは別個の policy container を持つため、 許可リストがサービスワーカーの許可リストと異なる文書で開始されたメッセージやリクエストに 応答することは十分にあり得る。この提案は他のポリシーの設計に従い、このような能力の違いを許容する。
開発者が service workers のリクエストを行う能力を制約したい場合、ワーカースクリプトとともに 許可リストを配信できるが、この許可リストが、その service worker が処理する可能性のある任意の文書の 許可リストのスーパーセットであることを保証する必要がある。
5.3. DNS
Connection Allowlists は、DNS リクエストを送信する前に許可リストをチェックするよう Fetch の
resolve an origin アルゴリズムを変更することで、
DNS ルックアップを通じたデータ流出のリスクを緩和することを目指す。これは、リクエストを送信する要素や API
(img
タグ、fetch()
など)の使用から生じる暗黙的なルックアップの両方に対処するだけでなく、
dns-prefetch のような機構によって
引き起こされる明示的なルックアップにも対処する。
とはいえ、許可リストは、特定のエンドポイントが許容可能かどうかを判断するために URL ベースの照合に依存している。これは DNS 操作に対する防御ではなく、リクエストに関与する DNS サーバー (DNS 解決の再帰的性質が複数のサーバーとの潜在的な通信を含むことも含めて)を制限するものではなく、 CNAME のような構成が許可リスト外のドメインに対する追加のルックアップを引き起こすことも制限しない。 同様に、許可リストは、DNS が指し示すサーバーが期待するサーバーであることを保証できない。
開発者は、認証済み接続に依存することで、DNS ハイジャックおよび/またはリバインディングのリスクを緩和するべきである。 セキュアなプロトコルのみを許可リスト化すれば、TLS ハンドシェイクが関連する名前を持つ証明書の所持を要求するため、 DNS を制御する攻撃者がトラフィックを任意のエンドポイントへ移すことがはるかに困難になる。
許可リストのパターンを セキュアなプロトコルを表すものに制限すべきだろうか。それとも非セキュアなオリジンではヘッダー全体を見送るべきだろうか。
5.4. postMessage(...)
この提案はネットワーク接続のみを扱う。これは、
postMessage(message, options)、
MessageChannel、
BroadcastChannel
などの明示的な通信チャネルによる通信も対象になると期待する開発者にとっては、意外かもしれない。
それらもすべて、許可リストと有意義に比較できるオリジンベースのモデルに適合するため、
モデルをそれらも含むよう拡張することは理にかなうかもしれない。
5.5. リダイレクト
デフォルトでは、Connection Allowlists はすべてのリダイレクトをブロックする。これは保守的な姿勢であり、 オープンリダイレクトやその他のサーバーサイドのリダイレクト機構を通じたデータ流出を防ぐことを目指す。 文書で許可リストが強制されている場合、リダイレクトを生じるすべてのリクエストは、 許可リストがそれらを明示的に許可するようオプトインしない限りブロックされる。
redirects パラメーターにより、
開発者はこの挙動を制御できる。
block(デフォルト)に設定された場合、
リダイレクトチェーン長が 1 より大きいすべてのリクエストはブロックされる。
allow に設定された場合、
許可リストは最初のリクエストに対してのみ強制される。最初のリクエストが許可リストに一致する場合、
その後のすべてのリダイレクトは、その場所に関係なく許可される。このモードは、データセキュリティの責任を
サーバーへ移す。リクエストがクライアントを離れることを許可された後は、サーバーがユーザーのデータを
信頼されていない場所へリダイレクトしないようにする責任を負う。
このアプローチは、アプリケーションごとに異なるセキュリティ要件があることを認めるものである。 機密性の高いアプリケーションはすべてのリダイレクトをブロックすることを選択でき、 それ以外は信頼済みエンドポイントがリダイレクトを正しく処理することに依存できる。
Connection-Allowlist: ("https://api.example")
https://api.example/data へのリクエストが
https://api.example/new-data への 302 Found リダイレクトを返す場合、
リダイレクトはデフォルトでブロックされるため、そのリクエストは ブロックされる。
代わりにヘッダーが次のような場合:
Connection-Allowlist: ("https://api.example");redirects=allow
https://api.example/data への同じリクエストは 許可され、
その後の https://api.example/new-data(あるいは https://attacker.com/ であっても)への
リダイレクトも 許可される。
最後に、前方互換性のため、不明なトークンは allow として扱われる:
Connection-Allowlist: ("https://api.example");redirects=some-future-policy
この場合、redirects パラメーターは存在するが、その値
some-future-policy は不明である。
ユーザーエージェントはこれを allow として扱い、リダイレクトは 許可される。
これにより、既存サイトを壊すことなく、将来追加の挙動を導入できる可能性が残される。
5.6. WebRTC
デフォルトでは、Connection Allowlists はすべての WebRTC 接続をブロックする。これは保守的な姿勢であり、 URL パターンだけでは制約が難しい WebRTC 固有のネットワーク特性を通じたデータ流出のリスクを 緩和することを意図している。
webrtc パラメーターにより、開発者はこの挙動を制御できる。
block(デフォルト)に設定された場合、
WebRTC 接続を確立しようとするすべての試みはブロックされる。
allow に設定された場合、
WebRTC 接続は許可される。
Connection-Allowlist: ("https://api.example")
WebRTC はデフォルトでブロックされるため、WebRTC 接続を確立しようとするすべての試みは ブロックされる。
代わりにヘッダーが次のような場合:
Connection-Allowlist: ("https://api.example"); webrtc=allow
WebRTC 接続は 許可される。
6. 実装上の考慮事項
6.1. WebSockets
WebSocket 接続は、ws または wss スキームを指定するパターンではなく、
http および https パターンによってカバーされることを覚えておくと役に立つ。
establish a WebSocket connection する際、
ステップ 1 はそれらの WebSocket 固有のスキームを、それぞれ http と https に書き換える。
これは、"ws://socket.example" のようなパターンを含む許可リストは意図した効果を持たないことを意味する。
そのパターンはリソースリクエストに一致することが決してないためである。