接続許可リスト

コミュニティグループ報告書草案,

このバージョン:
https://wicg.github.io/connection-allowlists/
課題追跡:
GitHub
仕様内インライン
編集者:
Mike West (Google)

要約

Connection-Allowlist 機構は、あるコンテキストが他のサーバーと通信する能力に関する 一連の制約のための簡潔なポリシー言語と配信機構を提供する。目的は、 開発者が、問題に合うよう狭く調整された形で、明示的なデータ流出チャネルを 包括的に緩和できるようにすることである。

この文書のステータス

この仕様は Web Platform Incubator Community Group によって公開された。 これは W3C 標準ではなく、W3C 標準化過程上にもない。 なお、 W3C Community Contributor License Agreement (CLA) の下では、限定的なオプトアウトおよびその他の条件が適用される。 W3C Community and Business Groups について詳しく知る。

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. 脅威モデル

この提案は意図的に小さく、クライアントサイド攻撃および/または誤設定の、 具体的だが有用なニッチを対象としている:

1.2. Content Security Policy との重複

この提案は、特定のコンテキスト内でのリソース利用に対する制限についての Content Security Policy のアプローチ、 特に fetch directives と多くの共通点を持つ。それでもなお、 いくつかの理由から検討する価値があるように思われる:

  1. CSP のモデルは細かすぎる: 機密性の高いコンテキストからデータが流出するリスクを緩和したい開発者は、 リクエストの発行や接続の確立が可能な方法を網羅的にカバーする保護を必要とする。 CSP による、リクエストを個別に制御できる種類へ分類する方法は、この問題に取り組む方法としては誤っている。 Web フォントのリクエストを通じたデータ漏洩は、画像やスクリプトのリクエストを通じたデータ漏洩と同じくらい悪いからである。 これらのリクエスト種別を区別すると、単に無関係な疑問によって、合理的な防御を設計する過程が複雑化する。

  2. CSP の構文は十分に粒度が細かくない: CSP がサポートする host-source 文法は、レスポンスとともに配信される ヘッダーを本当に冗長なものにする。別個のポリシーは、URLPattern 構文へ移行する機会を提供する。 これは、より現代的で、柔軟で、標準化された照合構文を提供することで、CSP のアプローチに関して人々が提起してきた いくつかの不満を解決するだろう。

  3. CSP のカバレッジは不完全である: CSP は Fetch を通る HTTP リクエストをうまくカバーしているが、 Web プラットフォーム API が接続の確立を可能にする無数の方法を網羅的にカバーしているわけではない。 DNS プリフェッチと WebRTC は取りかかるべき良い例だが、CSP の脅威モデルにどのように適合するのかに まさに苦慮してきたものは他にも多い。狭い焦点と開発者への明示的な約束を持つ新しいポリシーを作成することで、 これらの議論には防御可能な答えと、仕様作成者への明確な権限が与えられるだろう。

2. 接続許可リスト

Connection Allowlist は、特定のコンテキストが接続を許可される URL patterns の集合を表す。 これは、以下の items を持つ struct である:

3. Connection Allowlist ヘッダー

Connection-Allowlist レスポンス header は、 コンテキストが接続を許可されるエンドポイントの集合を定義する、シリアライズされた URL パターン文字列のリストを含む。 この許可リストは特定のコンテキストに対して強制され、表明されたパターンに一致しない発信接続をブロックする。 Connection-Allowlist-Report-Only レスポンス header は report-only 変種であり、同じ方法で構文解析されるが、 発信接続をブロックせずに違反レポートのみを送信する。

これらの Connection Allowlist ヘッダーは structured headers であり、その値は listinner lists である。サーバーは任意の数の項目を含むリストを配信してよいが、 最初の項目だけが使用される。リスト内の追加の項目はすべて無視される。

inner list には、strings としてシリアライズされた URL Patterns、または token response-origin のいずれかを含めることができる。 これは responseURLorigin に一致するパターンを表す。予期しない値は無視される。

inner list は任意の parameters を持ってよい:

その他すべてのパラメーターは無視される。

3.1. 構文解析

response (response) が与えられたとき、 parse a response’s Connection Allowlists するには、次を行う:
  1. allowlists を空の list とする。

  2. header を、responseheader list から、 `Connection-Allowlist` という名前の structured field value を取得した結果とし、 それを list として扱う。

  3. headerresponseURL、および enforce が与えられたものとして、 Parse a Connection Allowlist header する。結果が null でない場合、それを allowlistsinsert する。

  4. header を、responseheader list から、 `Connection-Allowlist-Report-Only` という名前の structured field value を取得した結果とし、 それを list として扱う。

  5. headerresponseURL、および report が与えられたものとして、 Parse a Connection Allowlist header する。結果が null でない場合、それを allowlistsinsert する。

  6. allowlists を返す。

structured headerlist (list)、URL (response-url)、および disposition (disposition) が与えられたとき、 parse a Connection Allowlist header するには、次を行う:
  1. listsize が 0 である場合、null を返す。

  2. list[0] が inner list でない場合、null を返す。

  3. allowlist を、その dispositiondisposition である Connection Allowlist とする。

  4. list[0] 内の各 item について For each:

    1. serialized patternnull とする。

    2. itemtoken response-origin である場合:

      1. serialized pattern を、response-urloriginASCII serialization に設定する。

    3. itemstring である場合、 serialized patternitem に設定する。

    4. serialized patternnull である場合、 continue する。

    5. URL pattern を、null を基底 URL として serialized pattern が与えられたものとして build a URL pattern from an HTTP structured field value を実行した結果とする。

      このステップがエラーを投げる場合、 continue する。

    6. URL patternallowlistallowlistAppend する。

  5. list[0] の parameters 内の各 keyvalue について For each:

    1. keyreport-to であり、valuetoken である場合、allowlistreporting endpointvalue に設定する。

    2. keyredirects であり、valuetoken である場合:

      1. value が "block" である場合、allowlistredirectsblock に設定する。

      2. それ以外の場合、allowlistredirectsallow に設定する。

    3. keywebrtc であり、 valuetoken である場合:

      1. value が "block" である場合、allowlistwebrtcblock に設定する。

      2. それ以外の場合、allowlistwebrtcallow に設定する。

  6. allowlist を返す。

注: 構文解析アルゴリズムでは、 無効な入力をすべて飛ばしている。もっと厳格な構文解析を行うことも十分あり得るが、 それは将来の柔軟性を制限する可能性が高い。

3.2. 照合

確立される接続の種類によっては、処理対象となる request がある場合もあれば、 URL しかない場合、あるいはそれより少ない情報しかない場合もある。 たとえば dns-prefetch は、 ホストに対してのみ照合できる。以下のアルゴリズムは、これらのシナリオで接続許可リストのチェックがどのように機能するかを規定する:

URL (url) と connection allowlist (connection allowlist) が与えられたとき、 match a URL to a Connection Allowlist するには、 次のステップを実行する。これは success または failure を返す。
  1. urlis local である場合、success を返す。

  2. connection allowlistallowlist 内の各 pattern について For each:

    1. patternurl が与えられたものとして URL pattern matchingnull を返さない場合、success を返す。

  3. failure を返す。

host (host) と connection allowlist (connection allowlist) が与えられたとき、 match a host to a Connection Allowlist するには、 次のステップを実行する。これは success または failure を返す。
  1. connection allowlistallowlist 内の各 pattern について For each:

    1. input を新しい URLPatternInit dictionary とし、その hostnamepatternhostname component に設定する。

    2. host-only pattern を、 input、基底 URL としての null、および options としての空の map が与えられたものとして creating a URL pattern した結果とする。

    3. synthetic url を、 "https://" と host を連結したものを URL として parsing した結果とする。

    4. host-only patternsynthetic url が与えられたものとして URL pattern matchingnull を返さない場合、success を返す。

  2. failure を返す。

注: hostname component だけを持つ新しいパターンを作成し、 host 用の URL を合成することで、 任意のプロトコル、任意のポート、任意のパスなどでそのホストへのリクエストを許可し得るパターンが 許可リスト内に_少しでも_存在すれば、一致を返すことができる。

should url be blocked by Connection Allowlists アルゴリズムは、 URL (url)、environment (environment)、および connection allowlists (connection allowlists) の list を受け取り、 allowed または blocked のいずれかを返す:
  1. connection allowlists 内の各 connection allowlist について For each:

    1. urlconnection allowlistmatches する場合、 continue する。

    2. urlenvironment、および connection allowlist が与えられたものとして Report a violation する。

    3. connection allowlistdispositionenforce である場合、 blocked を返す。

  2. allowed を返す。

should request be blocked by Connection Allowlists アルゴリズムは、 request (request) を受け取り、allowed または blocked のいずれかを返す:
  1. allowlists を、requestpolicy containerconnection allowlists とする。

  2. allowlists 内の各 allowlist について For each:

    1. requestURL listsize が 1 より大きい場合:

      1. allowlistredirectsallow である場合、 continue する。

      2. requesturlrequestclient、および allowlist が 与えられたものとして Report a violation する。

        注: リダイレクトが ブロックされる場合、リダイレクト先について必要以上の情報を漏らすことを避けるため、 意図的に requesturl を報告し、その current url は報告しない。

      3. allowlistdispositionenforce である場合、 blocked を返す。

      4. Continue する。

    2. requesturlallowlistmatches する場合、 continue する。

    3. requesturlrequestclient、および allowlist が 与えられたものとして Report a violation する。

    4. allowlistdispositionenforce である場合、 blocked を返す。

  3. allowed を返す。

should host be blocked by Connection Allowlists アルゴリズムは、 host (host)、environment (environment)、および connection allowlists (connection allowlists) の list を受け取り、 allowed または blocked のいずれかを返す:
  1. connection allowlists 内の各 connection allowlist について For each:

    1. hostconnection allowlisthost-matches する場合、 continue する。

    2. hostenvironment、および connection allowlist が与えられたものとして Report a violation する。

    3. connection allowlistdispositionenforce である場合、 blocked を返す。

  2. allowed を返す。

should WebRTC be blocked by Connection Allowlists アルゴリズムは、 environment settings object (environment) を受け取り、 allowed または blocked のいずれかを返す:
  1. allowlists を、environmentpolicy containerconnection allowlists とする。

  2. allowlists 内の各 allowlist について For each:

    1. allowlistwebrtcallow である場合、 continue する。

    2. "webrtc"、environment、および allowlist が与えられたものとして Report a violation する。

    3. allowlistdispositionenforce である場合、 blocked を返す。

  3. allowed を返す。

3.3. 報告

他のポリシー機構と同様に、Connection Allowlists は、許可リストヘッダーで指定された Reporting API エンドポイントへ各違反を報告する。違反は、次の dictionary 型によって表される:

enum ConnectionAllowlistDisposition { "enforce", "report" };

dictionary ConnectionAllowlistViolationReport : ReportBody {
  USVString url;
  USVString connection;
  sequence<DOMString> allowlist;
  ConnectionAllowlistDisposition disposition;
};

ConnectionAllowlistViolationReportconnection は、許可リストに違反した接続の、シリアライズされた URL である。

ConnectionAllowlistViolationReportallowlist は、違反された allowlist である。

ConnectionAllowlistViolationReportdisposition は、allowlistdisposition である。

URL または string "webrtc" (resource URL)、environment (environment)、および connection allowlist (allowlist) が与えられたとき、 report a violation するには、次を行う:
  1. allowlistreporting endpointnull である場合、返す。

  2. violation を、新しい ConnectionAllowlistViolationReport とし、次のように初期化する:

url

environmentcreation URL を、 stripped for use in reports したもの。

connection

resource URLURL である場合、 resource URLstripped for use in reports したもの。

それ以外の場合、resource URL

allowlist

allowlistallowlist 内の各パターンをシリアライズした結果を含む新しいリスト

disposition

allowlistdisposition

  1. environment をコンテキストとして、"connection-allowlist" を type として、allowlistreporting endpoint を destination として、そして violation を data として与え、 Generate and queue a report する。

4. モンキーパッチ

4.1. Fetch との統合

同じ目的を果たす他のチェックと並んで、Fetch § 4.1 Main fetch に ブロッキングチェックを追加することで、requests を扱う:

Main Fetch において、ステップ 7 を次のように調整する:
  1. 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 originobtain a connection にフックする:

resolve an origin では、上記のホスト専用照合アルゴリズムを呼び出し、 あるホストへの接続を何らかのパターンが潜在的に許可できるかどうかを判定する。 できない場合、解決を失敗させる。
  1. should host be blocked by Connection Allowlists が、originhostenvironment、および allowlists に対して実行されたときに blocked を返す場合、 failure を返す。
obtain a connection では、現在のステップ 2 の前にチェックを追加する:
  1. should url be blocked by Connection Allowlists が、urlenvironment、および allowlists に対して実行されたときに blocked を返す場合、 failure を返す。

Fetch への変更では、 使用すべき許可リストと、報告に使用すべきコンテキストを識別するために、 低レベルアルゴリズムの呼び出し箇所へ追加情報を渡す必要がある。 代わりに、それらの呼び出し箇所自体にチェックを実行させた方がよいかもしれない。 私の感覚では、ロジックを集中化する方が成功しやすいが、個別対応のアプローチを取る方が単純かもしれない。

4.2. HTML との統合

上記を HTML に統合するために、policy container struct に、 connection allowlistslist を含む新しい connection allowlists item を追加する。 これは、create a policy container from a fetch response アルゴリズムにステップを追加することで設定される:

  1. responseresult で Integrity-Policy ヘッダーを構文解析する。

  2. resultconnection allowlists を、 response が与えられたものとして parsing a response’s Connection Allowlists した結果に設定する。
  3. 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) アルゴリズムはいずれも次のようにパッチされなければならない:

  1. should url be blocked by Connection Allowlists が、urlthisrelevant settings object、および thisrelevant settings objectpolicy containerconnection 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)MessageChannelBroadcastChannel などの明示的な通信チャネルによる通信も対象になると期待する開発者にとっては、意外かもしれない。 それらもすべて、許可リストと有意義に比較できるオリジンベースのモデルに適合するため、 モデルをそれらも含むよう拡張することは理にかなうかもしれない。

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 固有のスキームを、それぞれ httphttps に書き換える。 これは、"ws://socket.example" のようなパターンを含む許可リストは意図した効果を持たないことを意味する。 そのパターンはリソースリクエストに一致することが決してないためである。

適合性

文書の 慣例

適合性要件は、 記述的な表明と RFC 2119 の用語を組み合わせて表現される。 この文書の規範的部分におけるキーワード “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” は、RFC 2119 で説明されているように解釈される。 ただし、可読性のため、 この仕様ではこれらの語がすべて大文字で現れるとは限らない。

この仕様のすべてのテキストは、 明示的に非規範的と示された節、例、および注を除き、規範的である。[RFC2119]

この仕様における例は、“for example” という語で導入されるか、 規範的テキストから切り離されて class="example" によって、次のように示される:

これは有益な例の一例である。

有益な注は “Note” という語で始まり、 規範的テキストから切り離されて class="note" によって、次のように示される:

注: これは有益な注である。

索引

この仕様で定義される 用語

参照により定義される 用語

参考文献

規範的参考文献

[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
[DOCUMENT-POLICY]
Document Policy. コミュニティグループ報告書草案. URL: https://wicg.github.io/document-policy/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[REPORTING]
Douglas Creager; Ian Clelland; Mike West. Reporting API. URL: https://w3c.github.io/reporting/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC9651]
M. Nottingham; P-H. Kamp. Structured Field Values for HTTP. 2024年9月. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9651/
[SERVICE-WORKERS]
Monica CHINTALA; Yoshisato Yanagisawa. Service Workers Nightly. URL: https://w3c.github.io/ServiceWorker/
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[URLPATTERN]
Ben Kelly; Jeremy Roman; 宍戸俊哉 (Shunya Shishido). URL Pattern Standard. Living Standard. URL: https://urlpattern.spec.whatwg.org/
[WEB-BLUETOOTH]
Jeffrey Yasskin. Web Bluetooth. URL: https://webbluetoothcg.github.io/web-bluetooth/
[WEB-SMART-CARD]
Web Smart Card API. 非公式提案草案. URL: https://wicg.github.io/web-smart-card/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/
[WEBRTC]
Cullen Jennings; et al. WebRTC: Real-Time Communication in Browsers. URL: https://w3c.github.io/webrtc-pc/
[XHR]
Anne van Kesteren. XMLHttpRequest Standard. Living Standard. URL: https://xhr.spec.whatwg.org/

非規範的参考文献

[CSP-EMBEDDED-ENFORCEMENT]
Mike West; Antonio Sartori. Content Security Policy: Embedded Enforcement. URL: https://w3c.github.io/webappsec-cspee/

IDL 索引

enum ConnectionAllowlistDisposition { "enforce", "report" };

dictionary ConnectionAllowlistViolationReport : ReportBody {
  USVString url;
  USVString connection;
  sequence<DOMString> allowlist;
  ConnectionAllowlistDisposition disposition;
};

課題索引

Fetch への変更では、使用すべき許可リストと、報告に使用すべきコンテキストを識別するために、 低レベルアルゴリズムの呼び出し箇所へ追加情報を渡す必要がある。 代わりに、それらの呼び出し箇所自体にチェックを実行させた方がよいかもしれない。 私の感覚では、ロジックを集中化する方が成功しやすいが、個別対応のアプローチを取る方が単純かもしれない。
navigate() は現在の文書をナビゲーションの sourceDocument として渡す。これは少し見落としのように思われる。 議論を参照。
開発者が依存関係の許可リストを ある程度制御できるようにすることも理想的である。 required document policy[csp-embedded-enforcement]] のようなものに根ざした オプトイン機構を探ると役に立つかもしれない。[WICG/connection-allowlists Issue #1]
許可リストのパターンを、セキュアなプロトコルを表すものに制限すべきだろうか。それとも、 非セキュアなオリジンではヘッダー全体を見送るべきだろうか。