分離されたコンテキスト

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

このバージョン:
https://wicg.github.io/isolated-web-apps/isolated-contexts.html
課題追跡:
GitHub
編集者:
(Google LLC)

Copyright © 2025 the Contributors to the Isolated Contexts Specification, published by the Web Platform Incubator Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

概要

この仕様は「分離されたコンテキスト」を定義する。これは、ユーザーエージェントの 実装者および仕様の著者が、分離と完全性の最低基準が満たされた場合にのみ、 特定の機能を有効にできるようにするものである。

この文書の位置づけ

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

1. はじめに

その存在を通じて、Web はますます高機能な アプリケーションプラットフォームへと発展してきた。Secure Contexts は転送のセキュリティを形式化し、Cross Origin Isolation はサイドチャネル攻撃を緩和し、ブラウザーとオペレーティングシステムは、 特定のファイルやデバイスを選択することに基づく許可インターフェイスを実験し、 アクセスをより範囲限定され、ユーザーにとって理解しやすいものにしてきた。これらの 進歩はいずれも、Web プラットフォームの安全性保証を向上させるか、 ページの動作に対するより正確な期待へとユーザーを導き、安全に Web にもたらすことのできる新しい種類の機能を解放した。

これらの進歩にもかかわらず、依然として Web に安全に公開できない API が存在する。 それらは、合理的に対処できない形で Web のセキュリティプリミティブに違反しているか、 あるいは、サイトへのアクセスを許可するかどうかについてユーザーが 十分な情報に基づいて判断できるほど明確には説明できないためである。プラットフォームが、 特定のサイトに API を公開することが安全であると証明できないなら、 信頼は外部の証明に由来しなければならない。

ページの安全性または動作に関するいかなる主張も、そのページの 内容と動作を知っていることを必要とする。証明は、保証されたコードが 実行されているコードと同じである場合にのみ意味を持つ。このため、 信頼判断を委譲するあらゆるシステムは、実行しているコードの完全性を 検証できなければならない — すなわち、それが信頼を委譲されたコードと 一致していることを知っていなければならない。

さらに、Web の現在のセキュリティモデルに収まらない機能は、 他の Web コンテンツにリスクをもたらす可能性がある。このリスクは 双方向である。サンドボックスを貫通する機能は他のサイトを攻撃するために 使用され得るし、強力な機能へアクセスできることは、そのサイトを悪意ある者にとって より魅力的な標的にする。これらのリスクを緩和するため、この仕様で 説明される仕組みを通じて機能へのアクセスを許可されるあらゆるコンテンツは、 ユーザーの通常の閲覧セッションから分離されなければならない。

この仕様は、分離されたコンテキストを定義する。これは、 完全性と分離の最低基準を満たす環境であり、信頼性証明の目的で Web コンテンツを監査する手段を提供し、このコンテンツをユーザーの 他の閲覧データから分離するものである。

この仕様はユーザーエージェントが提供する機能に焦点を当てているが、 分離されたコンテキストは、その脅威モデルが Web のセキュリティモデルによって 満たされない任意の Web ページ機能に有益であり得る。たとえば、 一部のエンドツーエンド暗号化チャットアプリケーションの脅威モデルには サーバー侵害が含まれるが、これは今日の Web では防御されていない。 分離されたコンテキストによって可能になる監査可能性と証明により、 これらのアプリケーションは実行しているコードの完全性と出所に 確信を持つことができる。

2. 分離されたコンテキスト

分離されたコンテキストは、 既存の仕様に対する一連の § 3 モンキーパッチを通じて 定義される。

完全性は、クロスオリジンの実行可能コンテンツが読み込まれないことを保証する 厳格な [CSP] と、ページ内に読み込まれた コンテンツを検証する抽象的な仕組みである完全性検証アルゴリズムの 組み合わせによって検証される。この仕様は特定の検証方法を義務付けず、 環境が分離されたコンテキストであるかどうかを判断するために、 それがどのように使用されるかだけを定義する。

2.1. どの API が分離されたコンテキストを必要とすべきか?

可能な限り少なくすべきである。分離されたコンテキストにのみ公開できる API は、 Web の少なくとも 1 つの設計 原則に違反している可能性が非常に高く、最も一般的には、Web ページを訪問することは安全であるべき という原則である。API を使用するために分離されたコンテキストを 要求する前に、次の質問を検討すること:

  1. この API が解決しようとしている問題に対処する唯一の方法は、新しい Web Platform API なのか? Web Extensions やネイティブアプリケーションにも役割がある。

  2. ある機能をユーザーに明確に伝えられない場合、その問題を解決する、 ユーザーにとってより理解しやすく、どのコンテンツがそれにアクセスできるかについて 十分な情報に基づいた判断を可能にする別の方法はあるか?

  3. 平均的な Web ページに公開された場合にも許容できないリスクを もはや生じないように、API の範囲を縮小できるか?

代替手段が見つからない場合、最後の手段として、API を分離された コンテキスト内で実行することを要求することを検討できる。

Web をこれほどユニークで成功したプラットフォームにしている要素の 1 つは、 ゲートキーパーの不在である。誰でもドメイン名を購入し、 他者の承認なしに自分のコンテンツをホストでき、Web Platform の API 表面へ 完全にアクセスできる。誰もが対等な立場にある。分離されたコンテキストが 提供するセキュリティ保証は監査可能性を可能にし、それがさらに証明を可能にする。 ブラウザーベンダーまたは第三者による証明が提供する安全性が、 API が分離されたコンテキストに制限される主な理由である。証明サービスを 提供する主体は、Web Platform のゲートキーパーとなる可能性があり、 これはプラットフォームが進むべき望ましい方向ではない。ブラウザーベンダーは、 分離されたコンテキストで許可する API について極めて選択的でなければならない。 可能な場合には、API を Secure Context で使用できるように変更することが 強く優先されるべきである。

2.2. UI の扱い

この仕様は、完全性と分離を達成するために必要な技術的要件に焦点を当てているが、 分離されたコンテキストが強力な機能を有効にするために使用される場合、 ユーザーの期待に反しないことも重要である。

ユーザーが Web を信頼しているのは、Web ページは安全であり、デバイスへの アクセスは制限されており、そのアクセスを自分が制御していると 教えられてきたためである。Web Platform 上のすべての API は、 Web ページを訪問することは 安全であるべきことを確保するという目標のもと、この目的に向けて 慎重に設計されてきた。

ブラウザーベンダーは、分離されたコンテキストに制限される機能が、 Web ページに何ができるかについてのユーザーの期待に反しないかどうかを 検討すべきである。これらの期待に反することは、そのサイトへの信頼を 損なうだけでなく、Web Platform 全体に対するユーザーの信頼を損なう リスクがある。

これを緩和するため、ユーザーエージェントは、分離されたコンテキスト内で 実行されるコンテンツが典型的な Web コンテンツではないことを ユーザーに伝えるための措置を講じるべきである。これには、 インストールフローまたは Web App UI の扱いが含まれ得る。

3. モンキーパッチ

この仕様は、既存の仕様に対して次のモンキーパッチを行う:

3.1. Content Security Policy

[CSP] では、 CSP list 内に含まれる ポリシーの集合体の強度を評価するアルゴリズムを定義する。 いくつかの補助アルゴリズムも定義するが、§ 3.1.1 ポリシーは インジェクション攻撃を意味のある形で緩和するか? が、CSP が HTML に公開する 中核的な入口点である。

3.1.1. ポリシーはインジェクション攻撃を意味のある形で緩和するか?

CSP list policies は、次のアルゴリズムが "Meaningful" を返す場合、インジェクション攻撃を意味のある形で 緩和すると言われる。返り値として可能な値は "Meaningful" および "Not meaningful enough" である。

  1. meets object requirements、meets base requirements、meets script requirements、meets style requirements、meets subresource requirements、および meets trusted type requirements を、 値が false である boolean とする。

  2. policies 内の各 policy について、反復する:

    1. policy の disposition が "enforce" でない、 または policy の source が "header" でない場合、continue する。

    2. policy が プラグインを十分に緩和する場合、 meets object requirements を true に設定する。

    3. policy が 相対 URL 操作を十分に 緩和する場合、meets base requirements を true に設定する。

    4. policy が スクリプト実行を十分に緩和する場合、 meets script requirements を true に設定する。

    5. policy が スタイル評価を十分に緩和する場合、 meets style requirements を true に設定する。

    6. policy が 安全でないサブリソースを十分にブロックする場合、 meets subresource requirements を true に設定する。

    7. policy が DOM シンクを十分に緩和する場合、 meets trusted type requirements を true に設定する。

  3. meets object requirements、meets base requirements、meets script requirements、meets style requirements、meets subresource requirements、および meets trusted type requirements がすべて true である場合、"Meaningful" を返す。

  4. "Not meaningful enough" を返す。

3.1.2. 型に対する有効なディレクティブを取得する

CSP は、一部のディレクティブについて、与えられたポリシーを評価する際に 考慮する必要があるフォールバックチェーンを定義する。policy policy と directive name が与えられたとき、有効なディレクティブを取得するには:

  1. fallback chain を、directive name に対して Get fetch directive fallback list を実行した結果とする。

  2. fallback chain 内の各 name について、反復する:

    1. policy の directive set が、その name が name である directive directive を 含む場合、 directive を返す。

  3. null を返す。

3.1.3. ポリシーはプラグインを十分に緩和するか?

policy policy は、 次のアルゴリズムが "Sufficient" を返す場合、プラグインを十分に緩和する。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. policy から、"object-src" が与えられたものとして active directive を 取得する。

  2. 次のすべてが true である場合、"Sufficient" を返す:

  3. "Not sufficient" を返す。

3.1.4. ポリシーは相対 URL 操作を十分に緩和するか?

policy policy は、次のアルゴリズムが "Sufficient" を返す場合、相対 URL 操作を十分に緩和する。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. policy の directive set 内の各 directive について、反復する:

    1. 次のすべてが true である場合、"Sufficient" を返す:

  2. "Not sufficient" を返す。

3.1.5. ポリシーはスクリプト実行を十分に緩和するか?

policy policy は、次のアルゴリズムが "Sufficient" を返す場合、スクリプト実行を十分に緩和する。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. policy から、"script-src" が与えられたものとして active directive を 取得する。

  2. 次のすべてが true である場合、"Sufficient" を返す:

  3. "Not sufficient" を返す。

3.1.6. ポリシーはスタイル評価を十分に緩和するか?

policy policy は、 次のアルゴリズムが "Sufficient" を返す場合、スタイル評価を十分に緩和する。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. policy の directive set 内の各 directive について、反復する:

    1. policy から、"style-src" が与えられたものとして active directive を 取得する。

    2. 次のすべてが true である場合、"Sufficient" を返す:

  2. "Not sufficient" を返す。

3.1.7. ポリシーは安全でないサブリソースを十分にブロックするか?

policy policy は、 次のアルゴリズムが "Sufficient" を返す場合、安全でない サブリソースを十分にブロックする。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. 集合 [frame-src, connect-src, img-src, media-src, font-src] 内の各 directive name について、反復する:

    1. policy から、directive name が与えられたものとして active directive を 取得する。

    2. active directive 内のいずれかの source expression が、 文字列 "'none'", "'self'", "https:", "blob:", または "data:" に対する ASCII case-insensitive 一致でない場合、 "Not sufficient" を返す。

  2. "Sufficient" を返す

3.1.8. ポリシーは DOM シンクを十分に緩和するか?

policy policy は、次の アルゴリズムが "Sufficient" を返す場合、DOM シンクを十分に緩和する。 返り値として可能な値は "Sufficient" および "Not sufficient" である。

  1. policy の directive set 内の各 directive について、反復する:

    1. 次のすべてが true である場合、"Sufficient" を返す:

  2. "Not sufficient" を返す。

3.1.9. 例

次の CSP はインジェクション 攻撃を意味のある形で緩和する:

base-uri 'none';
default-src 'self';
object-src 'none';
script-src 'self' 'wasm-unsafe-eval';
style-src 'self' 'unsafe-inline';
frame-src 'self' https: blob: data:;
connect-src 'self' https: blob: data:;
img-src 'self' https: blob: data:;
media-src 'self' https: blob: data:;
font-src 'self' blob: data:;
require-trusted-types-for 'script';

3.1.10. ポリシーは UI リドレッシング攻撃を意味のある形で緩和するか?

CSP list policies は、次のアルゴリズムが "Meaningful" を返す場合、UI リドレッシング攻撃を意味のある形で 緩和すると言われる。[UISECURITY] 返り値として可能な値は "Meaningful" および "Not meaningful enough" である。

  1. policies 内の各 policy について、反復する:

    1. policy の disposition が "enforce" でない、 または policy の source が "header" でない場合、continue する。

    2. policy の directive set 内の各 directive について、 反復する:

      1. 次のすべてが true である場合、"Meaningful" を返す:

  2. "Not meaningful enough" を返す。

3.2. HTML

HTML では、リソースの完全性検証に使用されるいくつかのプロパティと、 § 3.1 Content Security Policy で定義されたものと組み合わせて使用されるいくつかのアルゴリズムを定義し、 environment settings object の特性を定義する。 これらの特性は、与えられた IDL 構成要素が関連する global object 上に公開されるかどうかを判断する際に、 [WEBIDL] から 調べられる。

3.2.1. 完全性

完全性 検証アルゴリズムは、implementation-defined なアルゴリズムであり、request と response を受け取り、 boolean を返す。

注: 典型的な完全性 検証アルゴリズムは、 レスポンス本文が期待される値へハッシュされること、または既知の リソースバンドルに由来することを検証するかもしれない。

user agent は、オリジン完全性検証マップを保持する。 これは、tuple origins から 完全性 検証アルゴリズムへの map である。

注: ユーザーエージェントがオリジン完全性検証マップをどのように 設定するかは、この仕様の範囲外である。この仕様は、完全性と分離を 確立するために必要なプロパティに焦点を当てている。Isolated Web Apps は、インストール済みの Isolated Web Apps の集合に基づいてこのマップを構築する、1 つの実装可能性を提供する。

3.2.2. 環境設定オブジェクトのプロパティ

environment settings object は、その policy container の CSP list がインジェクション 攻撃を意味のある形で緩和する場合、インジェクション攻撃を意味のある形で緩和すると言われる。
environment settings object は、 その policy container の CSP list がUI リドレッシング 攻撃を意味のある形で緩和する場合、UI リドレッシング攻撃を緩和する と言われる。

注: CSP list に対する意味のあるインジェクションおよび UI リドレッシングの 緩和の定義は、ヘッダーで配信されたポリシーのみに依存するため、 これらのプロパティは環境の生存期間中に変化しない。

environment settings object environment は、 次のアルゴリズムが true を返す場合、分離されたコンテキストである:

  1. environment がインジェクション攻撃を意味のある形で 緩和しない場合、false を返す。

  2. environment の cross-origin isolated capability が concrete でない場合、false を返す。

  3. environment が UI リドレッシング攻撃を緩和しない場合、false を返す。

  4. origin を environment の origin とする。

  5. user agent の origin integrity verification map[origin] が存在しない場合、false を返す。

  6. true を返す。

3.3. Fetch

Fetch では、レスポンスが期待される内容を持っていることを検証するために、 § 3.2.1 完全性 で定義された 完全性検証アルゴリズムを使用する。

3.3.1. レスポンスの完全性を検証する

request request と response response が与えられたとき、レスポンスの完全性を検証するには、 これらの手順を実行する。返り値として可能な値は "not applicable", "invalid", または "valid" である。
  1. client を request の client とする。
  2. client が null の場合、"not applicable" を返す。
  3. origin を request の origin とする。
  4. user agent の origin integrity verification map[origin] が存在しない場合、"not applicable" を返す。
  5. integrity verification algorithm を、user agent の origin integrity verification map[origin] とする。
  6. response の body が null の場合、"invalid" を返す。
  7. request および response が与えられたものとして integrity verification algorithm を実行した結果が false である場合、 "invalid" を返す。
  8. "valid" を返す。

3.3.2. 「Main Fetch」アルゴリズムへのパッチ

main fetch アルゴリズムは次のように拡張される:
fetch params fetchParams と、任意の boolean recursive (既定は false) が与えられたとき、 main fetch するには、次の手順を実行する:
  1. request を fetchParams の request とする。
  2. response を null とする。
  3. request の integrity metadata が空文字列でない場合、 次を行う:
    1. ...
  4. レスポンスの完全性を検証するを request および response が与えられたものとして実行した結果が "invalid" である場合、fetchParams と network error が与えられたものとして fetch response handover を実行する。
  5. それ以外の場合、fetchParams と response が与えられたものとして fetch response handover を実行する。

注: 理想的には、完全性検証を [SRI] の integrity metadata およびその補助アルゴリズムと 統合したい。 そのためには、[SRI] 仕様が integrity metadata 文字列を扱う方法について、 かなりのリファクタリングが必要になる。これは将来追求する価値があるかもしれない。

3.4. WebIDL

WebIDL では、[IsolatedContext] 属性を定義し、 それを上記の HTML で作成されたフックに接続する:

3.4.1. [IsolatedContext]

[IsolatedContext] extended attribute が、interface、partial interface、interface mixin、 partial interface mixin、callback interface、namespace、partial namespace、interface member、interface mixin member、または namespace member 上に現れる場合、 その構成要素がexposed されるのは 分離されたコンテキスト内だけであることを示す。 [IsolatedContext] extended attribute は、他のいかなる構成要素にも使用してはならない。

[IsolatedContext] extended attribute は、引数を 取ってはならない。

[IsolatedContext] がoverloaded な operation 上に 現れる場合、それはすべてのオーバーロードに現れなければならない。

[IsolatedContext] extended attribute は、次のうち複数に 指定してはならない:

注: これは、含む側の定義も [IsolatedContext] extended attribute で注釈されている場合に、 member 上に [IsolatedContext] extended attribute を追加しても、 その member の公開をさらに制限しないためである。

[IsolatedContext] extended attribute を持たない interface は、 [IsolatedContext] を指定している別の interface から継承してはならない。

3.4.2. 「exposed」アルゴリズムへのパッチ

WebIDL の exposed アルゴリズムは次のように調整される。すなわち、 [CrossOriginIsolated] を同様に扱った後に、単一の手順を追加する (下記の手順 4)。

interface、callback interface、namespace、または member construct は、次の手順が true を返す場合、 与えられた realm realm 内で exposed される:
  1. construct の exposure set が * でなく、かつ realm.[[GlobalObject]] が construct の exposure set 内にある interface を実装していない場合、false を返す。
  2. realm の settings object が secure context でなく、かつ construct が [SecureContext] 上で conditionally exposed される場合、 false を返す。
  3. realm の settings object の cross-origin isolated capability が false であり、 かつ construct が [CrossOriginIsolated] 上で conditionally exposed される場合、false を返す。
  4. realm の settings object が分離された コンテキストでなく、 かつ construct が [IsolatedContext] 上で conditionally exposed される場合、 false を返す。
  5. true を返す。

3.5. Storage

obtain a storage key for non-storage purposes アルゴリズムは、user agent が完全性検証アルゴリズムを持つと知っている environment の top-level origin に属するすべてのストレージに対して、 ダブルキー化を要求するよう拡張される。

environment environment が与えられたとき、非ストレージ目的のストレージキーを取得するには、 次の手順を実行する:
  1. environment が environment settings object である場合は、 origin を environment の origin とする。そうでない場合は、 origin を environment の creation URL の origin とする。
  2. top-level origin を environment の top-level origin とする。
  3. user agent の origin integrity verification map [top-level origin] が存在する場合、 top-level origin と origin からなる tuple を返す。
  4. origin からなる tuple を返す。

注: これは本質的に、 Client-Side Storage Partitioning の 最小限に仕様化されたバージョンである。それが完全に仕様化され、必要な仕様へ マージされた場合、それらの変更はこのセクションを置き換え、 このセクションは削除できる。

適合性

文書の 慣例

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

この仕様のすべてのテキストは規範的である。 ただし、非規範的であると明示的に示されたセクション、例、および注を除く。 [RFC2119]

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

これは参考情報としての例の一例である。

参考情報としての注は “Note” という語で始まり、 class="note" によって 規範的テキストから区別される。 次のように:

Note, これは参考情報としての注である。

索引

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

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

参考文献

規範的参考文献

[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
[ECMASCRIPT]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[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/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[STORAGE]
Anne van Kesteren. Storage Standard. Living Standard. URL: https://storage.spec.whatwg.org/
[TRUSTED-TYPES]
Krzysztof Kotowicz. Trusted Types. URL: https://w3c.github.io/trusted-types/dist/spec/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

参考情報参考文献

[SECURER-CONTEXTS]
Mike West. Securer Contexts. URL: https://github.com/mikewest/securer-contexts
[SRI]
Devdatta Akhawe; et al. Subresource Integrity. URL: https://w3c.github.io/webappsec-subresource-integrity/
[STRICT-CSP]
Lukas Weichselbaum. Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP). 15 March 2021. URL: https://web.dev/strict-csp/
[UISECURITY]
Brad Hill. User Interface Security and the Visibility API. URL: https://w3c.github.io/webappsec-uisecurity/index.html