1. はじめに
この文書は、ウェブプラットフォームの一部として設定可能な機能を 設計するためのフレームワークであり、ウェブ開発者がサイトのデプロイの一環として それらの機能を設定できるようにする文書ポリシーを定義します。
2. 例 #
新しい例が必要です。現時点では、解説を参照してください。
3. その他および関連する仕組み
文書ポリシーは、文書設定のための既存のいくつかの仕組みと 適用範囲が似ていますが、それぞれとは大きな違いがあります。
3.1. Permissions Policy との関係
Permissions Policy [PERMISSIONS-POLICY] も、作者が文書内の機能を設定できるようにする 仕組みであり、適用範囲は似ていますが、 異なる継承の仕組みを使用しているため、 文書ポリシーによる制御に適した機能とは別の、 特定の種類の機能により適しています。
歴史的には、文書ポリシーは Permissions Policy(当時は Feature Policy と 呼ばれていました)への多数の機能追加提案に対応するために作成されました。 それらは既存の「feature」モデルにうまく適合しないか、 Permissions Policy 仕様にかなりの追加の複雑さを 導入する必要がありました。これには、パラメーターを持つ機能、 サブフレームへの継承を任意にできる機能、および 他のトップレベル閲覧コンテキストとは異なる方法でポップアップに 継承される機能が含まれていました。
これらの機能は現在、文書ポリシーで扱うことが提案されており、 Permissions Policy は委譲が主な 関心事項である機能に使用されます。Permissions Policy の機能は boolean 値 (有効または無効)であり、親で無効にされた場合は子フレームで 再び有効にすることはできず、一般に「トップレベル閲覧 コンテキストとその同一オリジンの子では利用可能であり、クロスオリジン フレームには委譲する必要がある」というモデルに従います。
対照的に、文書ポリシーによって制御される機能はパラメーターを取ることができ、 それらのパラメーターは異なるフレームで互いに無関係な値を持つことができます(親フレームで 機能を制約しても、必ずしもその子 フレームを制約するわけではありません)。
3.2. Content Security Policy との関係
Content-Security-Policy [CSP] も文書内の 「features」を設定しますが、 主としてページ内のリソースのオリジンに関係し、 読み込み後にそれらのリソースが何を行えるかを制御することではありません。
CSP はまた、sandbox ディレクティブを通じて、 文書にサンドボックスフラグを設定するための異なる仕組みも提供します。サンドボックスフラグが 文書ポリシーへ移された場合、2 つのヘッダーが 同一の情報をエンコードする可能性があるため、これは冗長になる可能性があります。
CSP-Embedded-Enforcement は、子文書にポリシーへの 準拠を強制し、Fetch 中に適合しない文書を ネットワークエラーとして拒否するモデルを導入しました。このモデルは、 必須ポリシーの仕組みとして文書ポリシーに採用されています。
3.3. サンドボックス化との関係
iframe のサンドボックス化も、文書内の機能を制御するための仕組みであり、 文書ポリシーの必須ポリシーと非常によく似た方法で動作します。 機能を無効にすることをフレームに課すことができ、 そのフレームへ読み込まれるすべてのコンテンツに影響します。
iframe の sandbox 属性によって制御される機能は、 文書ポリシーで非常に自然に表現できます。
iframe のサンドボックス化と文書ポリシーの重要な違いの 1 つは、 フレームで 'sandbox' 属性が使用された場合、 すべてのサンドボックス機能が既定で適用され、 1 つずつ再び有効にする必要があることです。このため、 サンドボックス化モデルを新しい機能で拡張することは非常に困難です。追加された機能は 既存のすべてのサンドボックス化されたコンテンツに即座に影響するためです。さらに、 オリジンサーバーには、そのコンテンツがサンドボックス化されることを知るための 仕組みがないため、サンドボックス化された文書内の制御フローを 変更する可能性のある新しいサンドボックス機能を追加することは困難です。これは、 既存のコンテンツに新たなセキュリティ脆弱性を 導入する可能性があるためです。
4. フレームワーク
4.1. 設定ポイント
設定 ポイントとは、文書ポリシーを通じて有効化、無効化、または設定できる ウェブプラットフォーム API または動作です。 設定ポイントは、基礎となる API または動作を記述する仕様で定義されるべきですが、 使用されている定義済みの 設定ポイントのレジストリがこの文書に付属しています。
設定 ポイントには、トークンである 名前があります。
設定 ポイントには、次のいずれかである 型があります。
-
boolean、 -
integer、 -
float、または -
enum。
設定 ポイントには、その 型のすべての値の部分集合である 範囲があります。
設定 ポイントには、その 範囲の要素である 既定値があります。
4.2. ポリシー
文書 ポリシーとは、設定 ポイントから ポリシー設定への順序付きマップです。
ポリシー 設定とは、設定ポイントの 範囲の要素である 値と、文字列であり null であってもよい 報告エンドポイントからなるタプルです。
閲覧コンテキストには、 文書 ポリシーである 必須文書ポリシーがあります。 null の オープナー 閲覧コンテキストを持つ 閲覧コンテキストは、空の 必須文書ポリシーを持ちます。
Document には、 文書 ポリシーである ネストされたコンテキストの必須文書 ポリシーがあります。
5. 必須ポリシーの直列化
-
ここでは、必須ポリシーが構造化 ヘッダーとしてどのように 直列化されるかを説明します。
-
正準形式が存在することを保証します(互換性テスト用)。
6. 報告
文書ポリシーをデプロイするサイトは、そのページに設定された
ポリシーのいずれかに違反があるかどうかを知りたい場合があります。たとえば、すべての画像が
そのコンテナーのサイズと一致することを要求するポリシーを設定しているサイトは、
新しい開発者や CMS がコンテンツにサイズ超過の画像を挿入した場合に
警告を受けたい場合があります。
同様に、document.write API の使用を制限するポリシーをデプロイしているサイトは、
それを使用するスクリプトがインポートされた場合に
報告を受けたい場合があります。
この節では、Reporting API を使用してそのような違反を報告する仕組みを定義します。 [REPORTING]
サイトは、ポリシーを強制する前に、 実際の環境で試したい場合もあります。この節では「Report-only」モードも定義します。このモードでは、 ユーザーエージェントはポリシー違反となる状況を監視し、 ポリシーを強制せずにそれらを報告できます。これによりサイト所有者は、 実際にポリシーをデプロイする前に、 実環境での違反数を許容可能なレベルまで減らすための作業を行えます。
報告は、ポリシーを設定するページからのみ可能です。 必須ポリシーに違反するネストされたページから報告を受け取ることはできません。
「違反」は機能ごとに定義されますが、常にユーザー自身の直接的な行動ではなく、 ウェブ開発者の行動を反映すべきです。
これは、すべてのポリシーを報告できるわけではないことを意味します。 マークアップやスクリプトの操作によって意味のある形で「違反」されたとは言えない設定を持つ 機能の種類があります。たとえば、 フォームフィールドへのテキスト入力を無効にする仮想的な機能は、 ユーザーエージェントによって強制できますが、 ユーザーがそのフィールドへの入力を試みて強制が 必要になったとしても、それはポリシー違反を表すものではなく、 報告すべきではありません。
6.1. 文書内報告の設定
6.1.1. 「report-to」パラメーター
どのディレクティブにも report-to という名前のパラメーターを含めることができ、
その機能の違反報告の送信先となる報告 エンドポイントを指定します。
例:
Document-Policy: something=1.0;report-to=endpoint1, something-else=?0;report-to=endpoint2
6.1.2. 既定の報告エンドポイントの設定
多数またはすべての機能の違反を同じエンドポイントへ送信すべき場合、
単一の既定の エンドポイントを定義する方が簡単な場合があります。これは、
特別なトークン * のパラメーターによって定義できます。既定の エンドポイントが
指定されている場合、別途指定されない限り、すべての違反
報告はその名前付きエンドポイントへ送信されます。機能が report-to パラメーターで
独自のエンドポイントも指定している場合、報告は代わりにその
エンドポイントへ送信されます。(報告は両方のエンドポイントには送信されません。)
例:
Document-Policy: something=1.0, something-else=?0, *;report-to=endpoint
6.1.3. 機能に対する報告の無効化
既定のエンドポイントが指定されている場合、特定の機能について
報告を無効にする必要がある場合があります。これは、report-to パラメーターの値として
特別なエンドポイント名 none を指定することで実現できます。
これにより既定のエンドポイントが上書きされ、その
機能について報告が無効になります。
例:
Document-Policy: something=1.0;report-to=none, something-else=?0,
*;report-to=endpoiont
6.2. 報告専用モード
文書ポリシーは「report-only」ポリシーにすることができます。報告専用ポリシーは
Document-Policy-Report-Only ヘッダーで指定されます。
報告専用ポリシーへの違反は、強制ポリシーの場合と同様に
報告を生成しますが、ユーザーエージェントに
その他の処理を実行させることはありません。
Document-Policy-Report-Only
report-to ディレクティブパラメーターは、この
ヘッダー内のディレクティブとともに使用すべきです。そうしない場合、それらはまったく効果を持ちません。
例:
Document-Policy-Report-Only: something=1.0;report-to=endpoint,
something-else=?0;report-to=endpoint2
7. 配信
7.1. 構造化ヘッダーとしてのポリシー
ポリシーは HTTP ヘッダーおよび HTML 属性で、 sh-dictionary 構造の直列化として表現されます。各辞書メンバーは 文書ポリシー ディレクティブです。
文書 ポリシーディレクティブは、直列化された文書 ポリシーの要素であり、sh-token である ディレクティブ名と、 関連付けられた パラメーターから構成されます。
ディレクティブ名は、次のいずれかです。
7.1.1. パラメーター
どの 文書ポリシーディレクティブにも、
値が文字列でなければならない report-to という名前のパラメーターを含めることができます。
文書ポリシーディレクティブの ディレクティブ名が、設定
ポイントを指し、その 型が boolean の場合、必須パラメーターはありません。
文書ポリシーディレクティブの ディレクティブ名が、設定
ポイントを指し、その 型が integer の場合、必須パラメーターを持ち、
その値は 設定ポイントの
範囲内の
integer でなければなりません。
文書ポリシーディレクティブの ディレクティブ名が、設定
ポイントを指し、その 型が float の場合、必須パラメーターを持ち、
その値は 設定ポイントの
範囲内の
decimal でなければなりません。
文書ポリシーディレクティブの ディレクティブ名が、設定
ポイントを指し、その 型が enum の場合、必須パラメーターを持ち、
その値は 'true' でなければならず、
その名前は 設定ポイントの
範囲内のトークンでなければなりません。
例:
-
boolean-feature -
boolean-feature=?0 -
integer-feature=2 -
float-feature=-0.2 -
enum-feature=state
7.2. HTTP ヘッダー
7.2.1. Document-Policy
`Document-Policy` HTTP
ヘッダーは、クライアントが強制すべき 文書ポリシーを
通知するため、レスポンス(サーバーからクライアント)で使用できます。
Document-Policy ヘッダーは Structured Header です。その値は
dictionary でなければなりません。その ABNF は次のとおりです。
Document-Policy = sh-dictionary
辞書メンバー名が、サポートされている設定ポイントまたは 特別な値「*」を指していない場合、その辞書メンバーは 処理手順によって無視されます。
7.2.2. Document-Policy-Report-Only
`Document-Policy-Report-Only`
HTTP ヘッダーは、文書の 報告専用文書ポリシーを設定するため、
レスポンス(サーバーからクライアント)で使用できます。
Document-Policy-Report-Only ヘッダーは Structured Header です。
その値は dictionary でなければなりません。Document-Policy
ヘッダーとまったく同じ構文を持ちます。
7.2.3. Require-Document-Policy
`Require-Document-Policy`
HTTP ヘッダーフィールドは、すべてのネストされた
コンテンツに適用する最小限の 必須文書ポリシーを
クライアントへ通知するために使用されるレスポンスヘッダーです。
Require-Document-Policy ヘッダーは Structured Header dictionary で、
Document-Policy ヘッダーとまったく同じ構文を持ちます。
7.2.4. Sec-Required-Document-Policy
`Sec-Required-Document-Policy`
HTTP ヘッダーフィールドは、そのリクエストに対して返される文書とともに
送信されなければならない 文書
ポリシーをサーバーに通知するために使用されるリクエストヘッダーです。
このヘッダーの値は、1 つ以上の 文書ポリシーディレクティブの § 5 必須ポリシーの直列化です。
7.3.
iframe 要素の policy
属性
iframe
要素には「policy」属性があり、必須
ポリシーディレクティブ(SH 形式)を含みます。
8. 統合
フレームに必須ポリシーがある場合、そのポリシーは、 ユーザーエージェントによって文書に適用される ポリシーをサーバーに知らせるため、外向きのすべての文書リクエストの リクエストヘッダーで通知されなければなりません。これにより、 サーバーは返される表現を変更して、その ポリシーに適合させることができます。
必須ポリシーのリクエストヘッダーが存在する場合、 レスポンスには互換性のある文書ポリシーヘッダーが含まれていなければならず、そうでない場合 fetch は失敗します。
8.1. HTML との統合
次の変更を [HTML] に組み込むべきです。
-
iframe要素に次の IDL を追加すべきです。
[CEReactions] attribute DOMString policy;
-
iframe の policy 属性は次のように定義すべきです。
-
policy属性は、指定された場合、初期化時にiframeの ネストされた閲覧コンテキストへ 必須 文書 ポリシーを追加します。その値は 直列化された文書ポリシーでなければなりません。
-
-
HTML § 3.1.1 Document オブジェクトに、次の行を追加します。
-
新しい閲覧コンテキストを作成する アルゴリズムで:
-
ステップ 5 の後に次のステップを追加します。
-
browsingContext の 必須文書 ポリシーを、browsingContext に対して 閲覧コンテキスト用の必須ポリシーを 作成する結果に設定します。
-
-
ステップ 9(現在は 10 に番号変更)を次のように変更します。
-
document を新しい Document とし、HTML 文書としてマークされ、quirks mode であり、その コンテンツ 型は
"text/html"、オリジンは origin、アクティブなサンドボックスフラグ集合 は sandboxFlags、permissions policy は permissions policy、 document policy は browsingContext の 必須文書ポリシーと同一であり、 post-load tasks の準備ができていて、かつ直ちに完全に読み込まれたものとします。
-
-
-
navigate fetch を処理するアルゴリズムで:
-
Document オブジェクトを初期化する アルゴリズムで:
-
ステップ 3 の後に次のステップを追加します。
-
documentPolicy を、browsingContext に対して response から 文書ポリシーを作成する結果とします。
-
nestedContextRequiredDocumentPolicy を、 browsingContext に対して response から ネストされた コンテキストの文書ポリシーを作成する結果とします。
-
-
ステップ 6(現在は 8 に番号変更)を次のように変更します。
-
document を新しい Document とし、その type は type、 content type は contentType、 origin は origin、permissions policy は permissionsPolicy、active sandboxing flag set は finalSandboxFlags、document policy は documentPolicy、 nested context required document policy は nestedContextRequiredDocumentPolicy とします。
-
-
8.2. Fetch との統合
次の変更を [FETCH] に組み込むべきです。
-
Fetch Standard § 2.2.5 Requests に次を追加します。
-
Fetch Standard § 4.6 HTTP-network-or-cache fetch のステップ 15 の後に、 次を挿入します。
-
httpRequest が 必須文書ポリシーを持つ場合、 次を行います。
-
serializedRequiredPolicy を、httpRequest の 必須文書 ポリシーに対して 必須 ポリシーを直列化するを呼び出した結果とします。
-
Sec-Required-Document-Policy/serializedRequiredPolicy を httpRequest の ヘッダーリストに付加します。
-
-
-
Fetch Standard § 4.1 Main fetch のステップ 11 のアルゴリズム一覧に、 次のアルゴリズムを追加します。
9. アルゴリズム
9.1. ポリシーは互換性があるか?
-
requiredPolicy 内の各 configuration point → value について:
-
declaredPolicy[configuration point] が存在しない場合、 false を返します。
-
value が declaredPolicy[configuration point] より厳格な場合、 false を返します。
-
-
true を返します。
9.2. 文書ポリシーを解析する
-
header が null の場合、null を返します。
-
policy を新しい順序付きマップとします。
-
defaultEndpoint を、null に設定された新しい文字列とします。
-
header 内の各 name->(value,parameters) について、
-
currentEndpoint を、null に設定された新しい文字列とします。
-
parameters["report-to"] が存在し、かつ文字列である場合:
-
currentEndpoint を parameters["report-to"] の値に設定します。
-
-
name が文字列「
*」である場合:-
defaultEndpoint を currentEndpoint に設定します。
-
-
そうでなく、name がサポートされている設定ポイントの名前である場合:
-
configuration point を、名前が name である サポートされている設定ポイントとします。
-
policy[configuration point] が存在する場合、 次の element へ進みます。
-
configuration point の型が boolean である場合:
-
value が Boolean でない場合、失敗します。
-
policy[configuration point] を、 ポリシー 設定の新しい boolean 値に設定します。その 値は value、報告 エンドポイントは currentEndpoint とします。
-
次の element へ進みます。
-
-
configuration point の型が enum である場合:
-
value が Token でない場合、失敗します。
-
value が configuration point の 許可された enum 値のいずれかの名前でない場合、失敗します。
-
policy[configuration point] を、 ポリシー 設定の新しい enum 値に設定します。その 値は value、報告 エンドポイントは currentEndpoint とします。
-
次の element へ進みます。
-
-
configuration point の型が integer である場合:
-
value が Integer でない場合、失敗します。
-
value が configuration point の範囲内にない場合、 失敗します。
-
policy[configuration point] を、 ポリシー 設定の新しい integer 値に設定します。その 値は value、報告 エンドポイントは currentEndpoint とします。
-
次の element へ進みます。
-
-
configuration point の型が float である場合:
-
value が Decimal でない場合、失敗します。
-
value が configuration point の範囲内にない場合、 失敗します。
-
policy[configuration point] を、 ポリシー 設定の新しい float 値に設定します。その 値は value、報告 エンドポイントは currentEndpoint とします。
-
次の element へ進みます。
-
-
-
-
policy 内の各 configuration point → config について、
-
config に 報告 エンドポイントがない場合、config の 報告 エンドポイントを defaultEndpoint に設定します。
-
-
policy を返します。
9.3. 必須ポリシーを直列化する
-
dict を新しい順序付きマップとします。
-
features を requiredPolicy のキーとします。
-
features を各要素の名前によって ASCII 順に並べ替えます。
-
features 内の各 feature について:
-
value を requiredPolicy[feature] とします。
-
dict[feature] を value に設定します。
-
-
dict の直列化を返します。
9.4. 閲覧コンテキスト用の 必須ポリシーを作成する
-
browsingContext が ネストされた閲覧コンテキストである場合:
-
requiredPolicy を browsingContext の コンテナー文書の ネストされたコンテキストの 必須文書 ポリシーの複製とします。
-
browsingContext の 閲覧コンテキストコンテナーが 「policy」属性を持つ場合:
-
containerPolicy を、その属性を解析した結果とします。
-
containerPolicy 内の各 feature -> value について:
-
requiredPolicy[feature] が存在しない場合、または value が requiredPolicy[feature] より厳格な場合、 requiredPolicy[feature] を value に設定します。
-
-
-
-
そうでない場合、requiredPolicy を新しい順序付きマップとします。
-
requiredPolicy を返します。
9.5. レスポンスから 文書ポリシーを作成する
-
requiredPolicy を、browsingContext を与えて 閲覧コンテキスト用の必須ポリシーを 作成するを実行した結果とします。
-
header を、response の ヘッダーリストから、 ヘッダー名
Document-Policyおよび型 「dictionary」を指定して 構造化フィールド値を 取得するを呼び出した結果とします。 -
declaredPolicy を、header に対して 文書 ポリシーを解析するを実行した結果とします。
-
declaredPolicy が requiredPolicy と 互換性がある場合、 declaredPolicy を返します。
-
例外をスローします。
9.6. レスポンスからネストされたコンテキストの 必須文書ポリシーを作成する
-
requiredPolicy を、browsingContext の 必須文書ポリシーの複製とします。
-
header を、response の ヘッダーリストから、 ヘッダー名
Required-Document-Policyおよび 型「dictionary」を指定して 構造化 フィールド値を取得するを呼び出した結果とします。 -
declaredNestedPolicy を、header に対して 文書ポリシーを 解析するを実行した結果とします。
-
declaredNestedPolicy 内の各 feature -> value について:
-
requiredPolicy[feature] が存在しない場合、または value が requiredPolicy[feature] より厳格な場合、 requiredPolicy[feature] を value に設定します。
-
-
requiredPolicy を返します。
9.7. 文書ポリシーによって リクエストへのレスポンスをブロックすべきか?
-
request が 必須文書 ポリシーを持つ場合:
-
documentPolicy を、response の ヘッダーリストから、 ヘッダー名
Document-Policyおよび 型「dictionary」を指定して 構造化 フィールド値を取得するを呼び出した結果とします。 -
documentPolicy が request の 必須文書 ポリシーと 互換性がない場合、 「blocked」を返します。
-
「valid」を返します。
-
9.8. 文書内の機能のポリシー値を取得する
9.9. 機能の値と ポリシーとの互換性を判定する
Document
オブジェクト
(document)が与えられたとき、このアルゴリズムは次からなるタプルを返します。
-
action。value が document の 文書ポリシーと互換性があるかどうかに応じて、 「compatible」または「incompatible」のいずれか。
-
報告エンドポイント名。value が document の 文書 ポリシーおよびその 報告専用 文書ポリシーの両方と互換性がある場合、または feature に対して報告が設定されていない場合は null、それ以外の場合は、違反報告を送信すべき 報告エンドポイントの名前。
強制ポリシーが報告専用ポリシーより厳格な場合、 報告専用ポリシーは検査されないことに注意してください。
-
policy を document の 文書 ポリシーとします。
-
policyConfig を、存在する場合は policy[feature]、 そうでない場合は feature の 既定値と null からなるタプルとします。
-
policyValue と reporting endpoint を policyConfig の要素とします。
-
policyValue が value より厳格な場合、 「incompatible」と reporting endpoint からなるタプルを返します。
-
report-only policy を document の 報告専用文書 ポリシーとします。
-
report-only policyConfig を、存在する場合は report-only policy[feature]、 そうでない場合は feature の 既定値と null からなるタプルとします。
-
policyValue と reporting endpoint を report-only policyConfig の要素に設定します。
-
policyValue が value より厳格な場合、 「compatible」と reporting endpoint からなるタプルを返します。
-
(「compatible」、null)を返します。
9.10. 値が 機能のポリシーと互換性があるかを判定し、必要に応じて報告する
Document
オブジェクト
(document)が与えられたとき、このアルゴリズムは value が
document の 文書ポリシーと互換性がある場合は「compatible」を返し、
そうでない場合は「incompatible」を返します。報告が設定されている場合は、
報告もキューに入れます。
-
(action、reporting endpoint)を、 value、feature、document を指定して 互換性を判定するを呼び出した結果とします。
-
reporting endpoint が null でない場合、
-
body を、次のプロパティを持つ新しい ECMAScript オブジェクトとします。 [ECMA-262]
- featureId
-
feature の文字列表現。
- sourceFile
-
null
- lineNumber
-
null
- columnNumber
-
null
- disposition
-
action が「incompatible」の場合は「enforce」、 そうでない場合は「report」。
-
ユーザーエージェントが現在スクリプトを実行中であり、settings から ソースファイルの URL、行番号、列番号を抽出できる場合、 body の sourceFile、lineNumber、columnNumber をそれに応じて設定します。
-
settings を document の 環境設定 オブジェクトとします。
-
body、「document-policy-violation」、reporting endpoint、 settings を指定して Reporting API § 2.3 宛先に対して型としてデータをキューに入れるを実行します。
-
-
action を返します。
9.11. 値が機能のポリシーと互換性があるかを 判定する
10. IANA に関する考慮事項
恒久的メッセージヘッダーフィールドレジストリは、 次の登録内容 [RFC3864] で更新されるべきです。
- ヘッダーフィールド名
- Document-Policy
- 適用可能なプロトコル
- http
- 状態
- standard
- 作者/変更管理者
- W3C
- 仕様文書
- Document Policy API
- ヘッダーフィールド名
- Require-Document-Policy
- 適用可能なプロトコル
- http
- 状態
- standard
- 作者/変更管理者
- W3C
- 仕様文書
- Document Policy API
- ヘッダーフィールド名
- Sec-Required-Document-Policy
- 適用可能なプロトコル
- http
- 状態
- standard
- 作者/変更管理者
- W3C
- 仕様文書
- Document Policy API
11. プライバシーとセキュリティ
この仕様は、埋め込み側ページが、
埋め込まれたページで強制されるポリシーを設定する仕組みを標準化します。ただし、既存の
iframe の
sandbox
の仕組みとは異なり、必須ポリシーへの明示的な承認が必要です。
これは、公開済みのウェブサイトにおける既存機能の動作を、
それらのサイトの協力なしに変更することはできないことを意味します。
このモデルについて留意すべきプライバシーおよびセキュリティ上の考慮事項が いくつかあります。
-
クロスオリジンサブフレーム内の動作が埋め込み側に公開されること。
-
ポリシーを通じて埋め込み側の状態が埋め込まれた文書に公開されること。
-
必須ポリシーを無条件に受け入れることによる、予期しない動作変更。
ある程度、これらの懸念はすでにウェブプラットフォームに存在しており、 この仕様は少なくとも、それらを不必要に悪化させないよう試みています。
セキュリティおよびプライバシー上の問題は、個々の 設定ポイントの設計によっても生じる可能性があるため、この 仕様と統合する際には注意が必要です。この節では、そのような問題を 引き起こし得る動作の種類について、いくらかの指針を提供します。
11.1. クロスオリジン動作の公開
設定ポイントは、フレーム化された文書内のポリシー違反が 他のフレーム内の文書から観測できないように設計すべきです。たとえば、 ポリシーによって無効にされているときに機能が使用されると 埋め込み側文書でイベントを発火する仮想的な機能は、 埋め込まれた文書の状態に関する情報を抽出するために使用され得ます。たとえば、 その機能がユーザーがサイトにログインしているときにのみ使用されることが分かっている場合、 埋め込み側はそのフレームでその機能を無効にし、その結果発生する イベントを監視して、ユーザーがログインしているかどうかを判定できてしまいます。
さらに、通常は文書から利用できない クロスオリジンリソースの内容に関する情報が、ポリシーによって 可視化されないよう注意する必要があります。たとえば画像の内容には機密 情報が含まれている可能性があり、細粒度のポリシーによって攻撃者が ポリシーの設定パラメーターを慎重に調整することで 画像の内容について何らかのことを推測できる可能性があります。サブリソースの内容に作用するポリシーは、 読み取り不能なリソースを除外するか、そのリソースについて 推測できる情報量を制限するための措置を講じるべきです。
11.2. 必須ポリシーの通知
上で説明した動作変更の問題を緩和するため、 必須ポリシーを持つフレーム内の埋め込みコンテンツへのリクエストは、 ポリシー要件の詳細を示す HTTP ヘッダーとともに送信されます。このヘッダーは オリジンサーバーから見ることができ、その内容は埋め込み側ページの詳細を 明らかにする可能性があります。埋め込み側は、埋め込みコンテンツに ポリシーを要求することを選択する際、この点を認識すべきです。
11.3. 必須ポリシーの無条件な受け入れ
読み込まれるためには埋め込み側が要求するポリシーに準拠する必要があるため、
サイト所有者は、ウェブサーバーを設定して、
Sec-Required-Document-Policy リクエストヘッダーをレスポンスの
Document-Policy ヘッダーにそのまま反映させたいと考えるかもしれません。
これにより文書のポリシーが常にリクエストと互換性を持つことは保証されますが、
既存 API の動作を無効化または変更することで、
埋め込み側が埋め込まれた文書内の制御フローを変更できる危険に
その文書をさらす可能性があります。これは特に、コンテンツが書かれた後に
新しい設定ポイントが文書ポリシーモデルへ追加された場合に当てはまります。
将来起こり得るすべての新しい動作変更に対して文書を
将来互換にすることは困難です。
必須文書ポリシーを持つコンテキストに埋め込まれることを想定するサイトは、 サポート可能であると分かっている実際の最も厳格なポリシーを 設定するか、把握していて、動作変更の潜在的な 範囲を理解している設定ポイントについてのみ、 受信したポリシーを反映することで、この問題を緩和できます。