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