コンテンツセキュリティポリシー: 埋め込み強制

W3C 作業草案,

この文書の詳細情報
このバージョン:
https://www.w3.org/TR/2026/WD-csp-embedded-enforcement-20260507/
最新公開バージョン:
https://www.w3.org/TR/csp-embedded-enforcement/
編集者草案:
https://w3c.github.io/webappsec-cspee/
以前のバージョン:
履歴:
https://www.w3.org/standards/history/csp-embedded-enforcement/
フィードバック:
public-webappsec@w3.org に、件名行 “[csp-embedded-enforcement] … メッセージのトピック …” を付けて送信してください (アーカイブ)
GitHub
編集者:
(Google Inc.)
(Google Inc.)
参加:
イシューを提出 (未解決のイシュー)
テスト:
web-platform-tests content-security-policy/embedded-enforcement/ (進行中の作業)

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

この文書は、ウェブページがフレームにCSP要件を課し、 特定の一連の制限を自身に強制することに同意する場合に限り、文書を埋め込むことを可能にする メカニズムを定義します。

この文書のステータス

この節は、公開時点におけるこの文書のステータスを説明するものです。 現在のW3C公開文書の一覧およびこの技術報告書の最新リビジョンは、 W3C技術報告書 インデックスで確認できます。

この文書は、 Web Application Security Working Groupによって、 Recommendation trackを用いた作業草案として公開されました。この文書はW3C勧告となることを意図しています。

この仕様の議論には、(アーカイブ済みの) 公開メーリングリスト public-webappsec@w3.org (手順を参照) を用いることが推奨されます。 電子メールを送信する際は、 件名に “csp-embedded-enforcement” というテキストを含めてください。 望ましくは、次のようにしてください: “[csp-embedded-enforcement] …コメントの要約…”

作業草案としての公開は、 W3Cおよびそのメンバーによる承認を意味しません。この文書は草案であり、 いつでも更新、置換、または 他の文書によって廃止される可能性があります。この文書を進行中の作業以外のものとして引用することは不適切です。

この文書は、 Web Application Security Working Groupによって作成されました。

この文書は、 W3C特許ポリシーの下で運営されるグループによって作成されました。 W3Cは、グループの成果物に関連して行われた 特許開示の公開リストを維持しています。 そのページには、特許を開示するための手順も含まれています。 個人が、Essential Claim(s)を含むと その個人が考える特許について実際の知識を有している場合、その情報を W3C特許ポリシー第6節に従って開示しなければなりません。

この文書は、2025年8月18日版W3Cプロセス文書によって管理されます。

1. はじめに

この節は規範ではありません。

Content Security Policyはクロスサイトスクリプティング攻撃に対する優れた防御策であり、 開発者が自身のサイトを悪意あるスクリプト、スタイル、およびその他の リソース型の注入から強化できるようにします。しかし、これにより開発者が iframeを介して読み込まれる サードパーティコンテンツに制限を適用できるようになるわけではありません。 CSPをこれらのサードパーティコンテキストに直接適用できるようにすることは危険です。 CSPはリソース読み込みに対して非常に粒度の細かい制御を提供し、特定のスクリプトへの アクセスを拒否することで、他の点では安全なページに脆弱性を導入してしまうことが十分に あり得ます。過去のX-XSS-Protectionのような機能で こうした問題が見られたため、新しい形でそれらを再導入しないよう注意しなければなりません。

とはいえ、ウィジェット、広告、およびその他の種類のサードパーティコンテンツに 制限を課すことができれば非常に有用です。この文書は、埋め込まれるコンテンツからの 明示的なオプトインに依存するメカニズムを提案します。これにより、ウィジェットが 埋め込み元と協力して妥当な一連の制限を交渉できるようになるはずです。

要するに、埋め込み元は iframe 要素に属性を設定することでContent Security Policyを提案します。このポリシーは、 フレーム内コンテンツに対するHTTPリクエストとともに、HTTPリクエストヘッダー (`Sec-Required-CSP`) として送信されます。 埋め込まれるコンテンツがそのポリシーを受け入れられる場合、 応答とともに `Content-Security-Policy` または `Allow-CSP-From` ヘッダーを返すことで、そのポリシーを強制できます。

応答が、埋め込み元が要求したポリシーと少なくとも同程度に厳格なポリシーを含む場合、 または埋め込み元が提供したポリシーを受け入れる場合、ユーザーエージェントは 埋め込まれたコンテンツをレンダリングします。そのような表明が存在しない場合、 応答はブロックされます。

1.1. 例

MegaCorp Inc.は、各種刊行物上で実行される広告が、安全性について監査済みの信頼できる オリジンからのスクリプトのみを含むようにロックダウンされることを確実にしたいと考えています。 これは、広告を iframe 要素と csp 属性を用いて含めることで実現できます: 
<iframe src="https://advertisements-r-us.example.com/ad1.cfm"
        csp="script-src https://trusted-cdn.example.com/">
</iframe>

これにより、次のように `Sec-Required-CSP` ヘッダーを持つリクエストがadvertisements-r-us.example.comに対して生成されます:

GET / HTTP/1.1
Host: advertisements-r-us.example.com
...
Sec-Required-CSP: script-src https://trusted-cdn.example.com/
...

広告サーバーはこのリクエストヘッダーを解析し、それが受け入れ可能であると判断して、 応答にヘッダーを追加し、埋め込み元（https://example.com）によって課された 制限に従うことをユーザーエージェントに通知します:

HTTP/1.1 200 OK
...
Allow-CSP-From: https://example.com
上記の例の広告サーバーは、埋め込み元が要求するポリシーと少なくとも同程度に強い 独自の `Content-Security-Policy` ヘッダーを発行することによっても、その制限を受け入れることができます。 たとえば、埋め込み元が何を許可しているかに関係なく、プラグインが読み込まれないことを 確実にしたい場合があります。これは、埋め込み元の制限を含み、さらに追加の制限を加えた ポリシーを発行することで実現できます: 
HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/; object-src 'none'

応答によって表明されたポリシーは、リクエストによって要求されたポリシーよりも 許可するリクエストが厳密に少ないため、フレームは正常に読み込まれます。

なお、サーバーは2つのポリシーを配信することもできます。一方は埋め込み元の制限を 正確に反映し、もう一方はそれらをさらに厳格化します:

HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/, object-src 'none'

`Content-Security-Policy` ヘッダーの値に含まれる「,」は、その文字列を2つの 直列化されたポリシーに分割し、それぞれが強制されます。ユーザーエージェントは、 応答とともに配信されたポリシーのうち1つが要件と一致することを検証します。 追加のポリシーはページの実効ポリシーをより制限的にすることしかできないため、 フレームの読み込みを正常に許可します。

2. フレームワーク

高いレベルでは、この文書は、埋め込まれる側が、埋め込み元によって指定された一連の 制限にオプトインできるメカニズムを説明します。このメカニズムにはいくつかの手順が含まれます:

  1. 埋め込み元は、 csp 属性を iframe 要素に設定することで、必要なポリシーを指定します。これは、§ 2.1 <iframe>のcsp 属性でより詳しく説明されています。

  2. その属性の値は、 iframeの 子ナビゲーブルを対象とする任意の ナビゲーションリクエストとともに、 `Sec-Required-CSP` リクエストヘッダーとして送信されます。このヘッダーは、 § 2.2 Sec-Required-CSP HTTP リクエストヘッダーでより詳しく説明されています。

  3. サーバーは、 `Sec-Required-CSP` ヘッダーを調べ、必要なポリシーを 受け入れるかどうかを判断できます。受け入れる場合、必要なポリシーと少なくとも 同程度に強いポリシーを含む `Content-Security-Policy` ヘッダーを応答で送信することによって暗黙的にオプトインできます。 または、埋め込み元オリジンが望む任意のポリシーを設定できるようにする `Allow-CSP-From` ヘッダーを応答で送信することによって明示的にオプトインできます。 明示的なメカニズムは単純であり、 § 2.3 Allow-CSP-From HTTPレスポンスヘッダーで 説明されています。暗黙的なメカニズムはかなり複雑であり、 § 3 暗黙的なポリシー受け入れ節全体で構成されます。

    サーバーが必要なポリシーを受け入れたくない場合、明示的なエラーを返すことも、 一致する `Content-Security-Policy` ヘッダーまたは `Allow-CSP-From` ヘッダーを付けずに通常のデータを単に返すこともできます。この場合、 ユーザーエージェントは応答をブロックします。HTMLの navigateアルゴリズムとのこの統合は § 2.4 HTMLとの統合で説明され、ブロックの メカニズムは§ 4.1 requestに対するresponseは requiredCSPによってブロックされるか?で詳述されています。

2.1. <iframe>のcsp属性

iframe 要素はcsp属性を持ちます。これは、 埋め込まれた文書が自身に強制することに同意しなければならない ポリシーを指定します。たとえば、次のHTMLは https://embedee.example.com/を読み込み、 object-src 'none'がそれに対して強制されることを保証します: 

<iframe src="https://embedee.example.com/" csp="object-src 'none'">
</iframe>

ある 文字列 (value) は、与えられた 要素 (element) の csp 属性について、次の文がすべて 真である場合に、有効な属性値です:

  1. valueは空文字列ではない。

  2. valueの長さは4096以下である。

    注: サーバーを 潜在的に混乱させる入力から保護するため、 csp 属性の値に最大長を課します。下記の§ 5.4 ヘッダー長を参照してください。

  3. valueは、[CSP]で定義される serialized-policy ABNF文法に一致する。

  4. 次の文のいずれかが真である:

    1. elementのノード文書のポリシーコンテナーのrequired CSPがnullである。

    2. valueを "enforce" として 解析した結果が、 elementのノード文書のポリシーコンテナーの required CSPによって 包含される。

  5. valueを "enforce" として 解析した結果が持つ ディレクティブ集合が、 次のディレクティブのいずれも 含まない:

次の文字列は、有効なCSP文法であるため、 csp 属性の有効な値です:

  • script-src 'none'

  • script-src 'self'; object-src 'none'; sandbox

  • not-a-directive https://whatever.not-a-tld

注: 将来のCSP構文との前方互換性を 保つため、最後の項目は意味のあるポリシーを表現していないにもかかわらず、 有効であると見なします。

一方、次のものはCSP構文に一致せず、有効な属性値とは見なされません:

  • script-src *\nInjected-Header: XSS!

  • 💩

注: csp 属性で許可する値には注意が必要です。その内容は最終的にHTTPリクエストヘッダーとして 反映されるためです。この懸念はで少し詳しく議論されています。

iframeの csp 属性には、次のWebIDL文法 [WEBIDL]によって定義される対応するIDL属性があります: 

partial interface HTMLIFrameElement {
  [CEReactions] attribute DOMString csp;
};

csp IDL属性は、要素の csp 属性を 反映しなければなりません。

これをすべての HTMLにアップストリームする。

2.2. Sec-Required-CSP HTTPリクエストヘッダー

埋め込まれたリソースが、埋め込み元の要件に従う意思があるかどうかを判断できるようにするため、 iframeの csp 属性で表現されたポリシーは、影響を受ける ナビゲーション リクエストとともに、 "Sec-Required-CSP" HTTPリクエストヘッダーを介して伝達されます。 ヘッダーの値は、次のABNF [RFC5234]によって表されます: 

Sec-Required-CSP = serialized-policy

ユーザーエージェントは、"Sec-Required-CSP"という名前のHTTPレスポンスヘッダーフィールドを 2つ以上送信してはならず（MUST NOT）、 そのようなヘッダーはいずれも複数の serialized-policyを含んではなりません（MUST NOT）。

サーバーは、受信した最初のそのようなヘッダー内の最初のポリシーのみを処理しなければなりません（MUST）。 で議論されるように、サーバーはポリシーを単純にクライアントへ 反映することの影響も慎重に考慮すべきです。サーバーが埋め込み元の要件を単に 受け入れたい場合、 `Allow-CSP-From` ヘッダーの方がより安全な選択です。

このヘッダーは、HTMLの navigateアルゴリズムの一部として設定されます（次のアルゴリズムを呼び出すフックの 詳細については§ 2.4 HTMLとの統合を参照してください）:

与えられた リクエスト (request) と 直列化された CSPまたはnull (requirement) について、 Sec-Required-CSP ヘッダーを設定するには、次の手順を実行する:

  1. requestが ナビゲーションリクエストでない場合、戻る。

  2. requirementがnullである場合、戻る。

  3. アサート: requirementは [CSP]で定義される serialized-policy 文法に一致する、直列化されたCSPである。

  4. "`Sec-Required-CSP`" という名前で、値がrequirementであるヘッダーを、 requestの ヘッダーリストに 付加する。

2.3. Allow-CSP-From HTTPレスポンスヘッダー

埋め込まれる側は、 "Allow-CSP-From" HTTPレスポンスヘッダーで応答することにより、 埋め込み元によって指定されたポリシーを受け入れることにオプトインできます。 ヘッダーの値は、次のABNF [RFC5234]によって表されます:

Allow-CSP-From = origin-or-null / wildcard

2.4. HTMLとの統合

  1. iframe 要素は、 § 2.1 <iframe>のcsp属性で定義される csp 属性を持つ。

  2. ポリシーコンテナー 構造体に required CSP項目を追加する。 これは直列化された CSPまたはnullであり、初期値はnullである。

  3. target snapshot params 構造体に required CSP項目を追加する。 これは直列化されたCSPまたはnullである。

  4. HTMLの snapshotting target snapshot params アルゴリズムを更新し、新しい required CSP項目を、 targetNavigableを与えて required CSPを決定する結果に設定する。

  5. navigation params 構造体に required CSP項目を追加する。 これは直列化された CSPまたはnullである。

  6. HTMLの navigateアルゴリズムを更新し、ステップ18.7.7で作成される navigation params 構造体の required CSPを、 targetSnapshotParamsのrequired CSPに設定する。

  7. HTMLの create navigation params by fetching アルゴリズムに、requestが作成された後で、次のステップを追加する:

    1. requestと targetSnapshotParamsのrequired CSPについて、 Sec-Required-CSP ヘッダーを設定する。

  8. create navigation params by fetching を更新し、返される navigation paramsの required CSPを、 targetSnapshotParamsの required CSPに設定する。

  9. create navigation params from a srcdoc resourceを更新し、返される navigation paramsの required CSPを、 targetSnapshotParamsのrequired CSPに設定する。

  10. HTMLの fetch応答からポリシーコンテナーを作成する アルゴリズムに、オプションのrequiredCSP （直列化された CSPまたはnull、既定値はnull）を引数として追加し、 次のステップを追加する:

    1. requiredCSPがnullでない場合:

      1. required policyを、requiredCSPを "enforce"として 解析した結果とする。

      2. response policiesを、 responseのContent Security Policiesを 解析した結果とする。

      3. § 3.2.1 CSPリストの包含を required policy、responseの urlの origin、response policies、 およびresponseの urlの originに対して実行したときに "Does Not Subsume"を返す場合:

        1. required policyを resultの CSPリストに 付加する。

        注: 応答のポリシーが すでに必要なポリシーを包含している場合、必要なポリシーを ポリシーコンテナーに追加しません。これにより、埋め込み元が 特定のnonce（例: nonce-abc）を要求し、埋め込まれる側が 独自の互換性のあるnonce（例: nonce-xyz）を提供した場合に、 ユーザーエージェントは埋め込まれる側のnonceだけを強制します。 両方を追加すると、どのスクリプトも両方のnonceを同時に満たせないため、 文書は事実上すべてのスクリプトをブロックすることになります。

      4. resultの required CSPを requiredCSPに設定する。

  11. create navigation params by fetching を更新し、 targetSnapshotParamsの required CSPを fetch応答からポリシーコンテナーを作成する に渡すようにする。

  12. HTMLの navigateアルゴリズムでナビゲーションを ブロックさせる条件のリストに、次を追加する（たとえばX-Frame-Optionsチェックの後）:

2.4.1. Required CSP

与えられた ナビゲーブル (navigable) について、 required CSPを決定するには、 次の手順を実行する:

  1. navigableが 子ナビゲーブルでない場合、nullを返す。

  2. navigableの コンテナーが、 有効な属性値 (value) を持つ csp 属性を持つ場合、 valueを返す。

  3. navigableの コンテナー文書の ポリシーコンテナーの required CSPを返す。

これをアップストリームする。

3. 暗黙的なポリシー受け入れ

埋め込まれる側は、応答とともに `Allow-CSP-From` ヘッダーを返すことで、埋め込み元によって指定されたポリシー要件を明示的に受け入れられます。 また、その要件は、埋め込み元が要求するポリシーと少なくとも同程度に厳格な 正味の効果を持つポリシー（またはポリシーの集合）を含む `Content-Security-Policy` ヘッダーを配信することによって、暗黙的に受け入れることもできます。

しかし、「少なくとも同程度に厳格」という表現はあまり精密ではありません。 単純な場合は明快です。埋め込み元がobject-src https://cdn.example.comを要求する場合、 埋め込まれる側はobject-src 'none'で応答できます。前者によってブロックされる 可能性のあるすべてのリソースは、後者によってもブロックされる（後者はオブジェクトをまったく 許可しない）ため、埋め込みはブロックしません。より複雑な場合には、CSPの構文上の複雑さにより、 これを推論することが少し難しくなります。たとえば、 script-src 'unsafe-inline' http: 'sha256-abc...def'が与えられた場合、 script-src 'unsafe-inline'は要求されたポリシーのサブセットであるように見えるかも しれません。しかし、 hash-source式が存在するため、 要求されたポリシーでは'unsafe-inline'は無視されます。したがって、見かけに反して、 後者のポリシーは実際には前者よりも多くを許可することになります。

ここでは、「少なくとも同程度に厳格」という概念を「包含」と呼びます。ある content security policy object (A) は、 Bによって許可されるすべてがAによっても許可される場合、別のもの (B)を 包含すると 言われます。この場合、 AはBを包含し、 またはBはAに包含されると言います。

ただし、常に単一のポリシーを比較しているわけではありません。複数のポリシーが CSP list に存在する場合、それらは "The effect of multiple policies"で 説明される複合効果を持ちます。ここでは、 CSP listの複合効果を、それらの 交差として扱います。詳細は下記の § 3.1 交差で詳述します。

交差を定義すれば、Aが CSP listを 包含するのは、かつその場合に限り、 Aがそのリストの交差を 包含する場合である、と言えます。

3.1. 交差

3.1.1. CSPリストの交差

CSP list (list) の、あるorigin (origin) に対する交差は、それらの正味の効果を表す単一の Content Security Policyオブジェクトであり、 次のアルゴリズムによって生成されます:

注: 複数のポリシーの交差を単一のポリシーとして表現することが 常に可能であるとは限りません。たとえば、script-src 'unsafe-inline'と script-src 'nonce-abc'を考えてください。 前者はインラインスクリプトのみを許可し、後者は特定のトークンを持つインラインまたは 外部化されたスクリプトのみを許可します。正味の効果（特定のトークンを持つインライン スクリプトのみ）は、単一のポリシーでは作成できません。そのようなポリシーの扱いは、 現時点では読者への演習として残されています。

読者にこの演習をさせるべきではありません。また、 単一のポリシーとして表現できない交差をどのように扱うか（例: ポリシーのリストを維持する）についても 指針を提供すべきです。

  1. resultを、空の ディレクティブ集合と、 "enforce"の dispositionを持つ content security policy objectとする。

  2. list内の各policyについて:

    1. policyのdispositionが "report"である場合、 continueする。

    2. resultを、originについてのresultと policyの 交差に設定する。

  3. resultを返す。

次の 直列化されたCSPのリスト内の各項目を解析して作成される ポリシーの交差: 
«
    "default-src 'self' http://example.com http://example.net; connect-src 'none';",
    "connect-src http://example.com/; script-src http://example.com/",
    "style-src 'self'; script-src http://example.com/ http://example.net",
»

は、次の直列化された CSPを解析して作成されるポリシーです:

"default-src 'self' http://example.com http://example.net; connect-src 'none'; script-src http://example.com/; style-src 'self'"

初期リストで指定された各ポリシーは、その交差を 包含します。

3.1.2. ポリシーの交差

2つの Content Security Policyオブジェクト（Aおよび B）の、あるorigin (origin) に対する 交差は、それらの複合効果を表す単一の Content Security Policyオブジェクトであり、 次のアルゴリズムによって生成されます:

  1. アサート: AとBはどちらも "enforce"の dispositionを持つ。

  2. Aの ディレクティブ集合が 空である場合、Bを返す。

  3. Bの ディレクティブ集合が 空である場合、Aを返す。

  4. policyを、空の ディレクティブ集合と、 "enforce"の dispositionを持つ新しい content security policy objectとする。

  5. directive namesを空の集合とする。

  6. A内の各directiveについて:

    1. directiveのnameをdirective namesに 付加する。

  7. B内の各directiveについて:

    1. directiveのnameをdirective namesに 付加する。

  8. directive names内の各directive nameについて:

    1. directive nameが"report-uri"または"report-to"である場合、 continueする。

    2. directive Aを、directive nameとAについての 有効ディレクティブ値とする。

    3. directive Bを、directive nameとBについての 有効ディレクティブ値とする。

    4. アサート: directive Aとdirective Bがどちらも nullであることはなく、かつ両方の 値がソース リストであるか、またはどちらの値も ソースリストではない。

    5. directive Aまたはdirective Bのいずれかが 値として ソースリストではないものを持つ場合、 continueする。

      ソースリストではないものを扱うために、 この定義を拡張する必要があります。また、より精密にする必要があり、おそらく directive nameに対して確認できる「ソースリストディレクティブ」のような 用語を定義すべきです。

    6. directive Aがnullである場合:

      1. directiveを、次のプロパティを持つ新しい directiveとする:

        name

        directive name

        value

        directive Bのvalue

      2. directiveを policyの ディレクティブ 集合に 付加する。

      3. Continueする。

    7. directive Bがnullである場合:

      1. directiveを、次のプロパティを持つ新しい directiveとする:

        name

        directive name

        value

        directive Aのvalue

      2. directiveを policyの ディレクティブ 集合に 付加する。

      3. Continueする。

    8. directive valueを、directive Aの value、directive Bのvalue、directive name、および originの 交差とする。

    9. directiveを、次のプロパティを持つ新しい directive とする:

      name

      directive name

      value

      directive value

    10. directiveをpolicyのディレクティブ集合に 付加する。

  9. policyを返す。

次の直列化されたCSPを 解析して得られるポリシーの交差: 
"default-src 'self' http://example.com http://example.net; connect-src 'none';"

and

"connect-src http://example.com/; script-src http://example.com/"

は、次の直列化された CSPを解析して得られるポリシーです:

"default-src 'self' http://example.com http://example.net; connect-src 'none'; script-src http://example.com/;"

与えられた2つのポリシーはいずれも、 交差を 包含します。たとえば、 交差の "script-src http://example.com/"は、1つ目のポリシーの "default-src 'self' http://example.com http://example.net"および2つ目のポリシーの "script-src http://example.com/"に 包含されます。

3.1.3. ソースリストの交差

2つのソースリストの、 あるディレクティブ名 (name) およびある origin (origin) に対する 交差は、それらの正味の効果を表す ソースリストです。 そのようなソースリストが存在しない場合 （たとえば、A内のhttps://example.com/と B内のhttps://not-example.com）、交差は リスト« 'none' »になります。

  1. effective Aを、A、name、およびoriginについての 有効ソースリストとする。

  2. effective Bを、B、name、およびoriginについての 有効ソースリストとする。

  3. effective Aまたはeffective Bのいずれかが« 'none' »である場合、« 'none' »を返す。

  4. effective Aが空である場合、effective Bを返す。

  5. effective Bが空である場合、effective Aを返す。

  6. schemesを空の集合とする。

  7. intersectionを空のソースリストとする。

  8. effective B内の各expression Bについて:

    1. expression Bがscheme-source文法に一致し、 かつexpression Bが effective Aに含まれる場合、expression Bを schemesに付加する。

      注: 上記で 有効ソースリストを取得することは、 scheme-source文法に一致する トークンがすでに正規化されており、 "http:"/"ws:"が "https:"/"ws:"も現れることなく現れることはない、という意味です。

  9. schemes内の各expressionについて:

    1. expressionが"https:"に一致しない、またはschemesが "http:"を含まない場合:

      1. expressionが"wss:"に一致しない、またはschemesが "ws:"を含まない場合、expressionを intersectionに付加する。

  10. effective A内の各expression Aについて:

    1. expression Aがscheme-source文法に一致し、 かつschemesがexpression Aを 含む場合、 continueする。

    2. effective B内の各expression Bについて:

      1. expression Aとexpression Bのうち少なくとも一方が、 scheme-sourceまたはhost-source文法に 一致しない場合:

        1. expression Aがkeyword-source 文法に一致し、かつexpression Bに対する ASCII大文字小文字不区別一致である場合、 expression Aをintersectionに 付加する。

        2. expression Aがnonce-source または hash-source 文法に一致し、かつexpression Bで ある場合、 expression Aをintersectionに 付加する。

        3. 次の expression Bへ Continueする。

      2. expression Bのscheme-partが schemes内の要素の1つに一致する場合、次のexpression Bへ continueする。

      3. expression Aとexpression Bの 交差が nullでない場合、その結果をintersectionに 付加する。

  11. intersectionを返す。

これらの場合、intersectionはAとBについての 交差です。 
A = wss: http://example.com
B = https: wss: 'none'
intersection = wss: https://example.com

式"wss:"は両方のポリシーに存在するため、それらの交差にも存在します。 同様に、"http://example.com"は、"http://example.com"と"https:"の両方に包含される唯一の式であるため、 交差に存在します。なお、"'none'""はB内の唯一のトークンではないため無視されます。

A = http://sub.a.com http://*.b.com
B = https://sub.a.com:* http://*.c.com
intersection = https://sub.a.com

類似するソースは2つだけです。A内の"http://sub.a.com"は B内の"https://sub.a.com:*"と類似しているため、2つのソースリストの交差は "https://sub.a.com"になります。 

A = 'unsafe-inline' http://example.com:443/page1/html 'nonce-abc'
B = 'unsafe-inline' https://example.com:443/ 'strict-dynamic' 'nonce-abc'
intersection = 'nonce-abc'

"strict-dynamic"はnonce-sourceおよび hash-source式のみを尊重するため、 Bは実効的には"'strict-dynamic' 'nonce-abc'"です。 そのため、交差は"'nonce-abc'"になります。

3.1.4. ソース式の交差

ソース式は、scheme-sourceまたはhost-source文法に一致する他の2つの式 AおよびBの、より制限的なscheme-part、 host-part、port-part、およびpath-partを含む場合、それら2つの式の 交差であると言われます。

これらの場合、IntersectはAとBの 交差です。 
A = https:
B = http:
Intersect = https:
// http:はhttp:とhttps:の両方を許可するため、https:が交差である。

A = http://*.example.com
B = https://sub.example.com:*
Intersect = https://sub.example.com:443
// Aはポートを指定していないため、既定のポートのみが許可される。

A = http://example.com:80/page1/html
B = https://example.com:443/
Intersect = null
// Aは明示的にポート80に固定されており、Bの同じく明示的なポート443とは一致できない。

A = https:
B = http://example.com
Intersect = https://example.com.

A = https://sub.example.com:*
B = http://*.example.com/page.html
Intersect = https://sub.example.com/page.html
3.1.4.1. scheme-sourceと host-sourceの交差
scheme-sourceまたは host-source文法に一致する2つの ソース式（Aおよび B）が与えられたとき、 AがBと source-expression similarである場合、それらの交差を返す。そうでない場合、 nullを返す。

  1. AがBと source-expression similarでない場合、 nullを返す。

  2. sourceを空文字列とする。

  3. scheme Aを、存在する場合はAのscheme-part、そうでない場合は nullとする。

  4. scheme Bを、存在する場合はBのscheme-part、そうでない場合は nullとする。

  5. more secure scheme Bを、scheme Aが scheme Bにscheme-part matchしない場合は true、そうでない場合はfalseとする。

  6. scheme Aがnullでなく、かつmore secure scheme Bが falseである場合、scheme Aと":"をsourceに付加する。 そうでない場合、scheme Bがnullでなければ、scheme Bと":"を sourceに付加する。

  7. AとBがどちらもscheme-source文法に一致する場合、 sourceを返す。

  8. sourceが空でない場合、"//"をsourceに付加する。

  9. host Aを、存在する場合はAのhost-part、そうでない場合は nullとする。

  10. host Bを、存在する場合はBのhost-part、そうでない場合は nullとする。

  11. host Aがnullでない場合:

    1. host Bがnullである場合、host Aを sourceに付加する。メインアルゴリズムの次のステップへ進む。

    2. Aがscheme-source文法に 一致せず、かつ ワイルドカードホストを持たない場合、 host Aをsourceに付加する。

    3. そうでない場合、host Bをsourceに付加する。

  12. host Aがnullである場合、host Bをsourceに付加する。

  13. port Aを、存在する場合はAのport-part、そうでない場合は nullとする。

  14. port Bを、存在する場合はBのport-part、そうでない場合は nullとする。

  15. port Aがnullである場合、port Bが nullでなければ、":"とport Bをsourceに付加する。

  16. port Aがnullでない場合:

    1. port Bがnullである場合、":"とport Aを sourceに付加する。メインアルゴリズムの次のステップへ進む。

    2. Aがワイルドカードポートを持たず、 かつmore secure scheme Bが falseである場合、":"とport Aをsourceに付加する。

    3. そうでない場合、":"とport Bをsourceに付加する。

  17. path Aを、存在する場合はAのpath-part、そうでない場合は nullとする。

  18. path Bを、存在する場合はBのpath-part、そうでない場合は nullとする。

  19. path Aがnullである場合、path Bが nullでなければ、path Bをsourceに付加する。

  20. path Aがnullでない場合:

    1. path Bがnullである場合、path Aをsourceに付加した結果を返す。

    2. path Aがpath Bにpath-part matchesする場合、 path Aをsourceに付加する。

    3. そうでない場合、path Bをsourceに付加する。

  21. sourceを返す。

3.1.5. 交差ヘルパー

3.1.5.1. 有効ディレクティブ値
文字列 (name) と content security policy object (policy) が 与えられたとき、 nameと policyについての有効ディレクティブ値は、次の手順を実行した結果得られる valueである:

  1. nameについて分岐し、関連付けられた手順を実行する:

    "child-src"
    "connect-src"
    "font-src"
    "img-src"
    "manifest-src"
    "media-src"
    "object-src"
    "script-src"
    "style-src"

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

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

      2. nullを返す。

    "script-src-elem"
    "script-src-attr"

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

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

      2. policyのdirective setが、含むdirectiveの nameが "default-src"である場合、そのdirectiveの valueを返す。

      3. nullを返す。

    "style-src-elem"
    "style-src-attr"

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

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

      2. policyのdirective setが、含むdirectiveの nameが "default-src"である場合、そのdirectiveの valueを返す。

      3. nullを返す。

    "frame-src"

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

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

      2. policyのdirective setが、含むdirectiveの nameが "default-src"である場合、そのdirectiveの valueを返す。

      3. nullを返す。

    "worker-src"

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

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

      2. policyのdirective setが、含むdirectiveの nameが "script-src"である場合、そのdirectiveの valueを返す。

      3. policyのdirective setが、含むdirectiveの nameが "default-src"である場合、そのdirectiveの valueを返す。

      4. nullを返す。

    "base-uri"
    "block-all-mixed-content"
    "default-src"
    "frame-ancestors"
    "form-action"
    "plugin-types"
    "report-uri"
    "require-sri-for"
    "sandbox"
    "upgrade-insecure-requests"

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

      1. nullを返す。

  2. nullを返す。

3.1.5.2. 有効ソースリスト
ソースリスト (list)、文字列 (name)、および origin (origin) が与えられたとき、 list、name、 および originについての有効ソースリストは、listを単純化したものであり、 'self'や*のような複雑なトークンを展開し、効果のない、 置き換えられた、または無効なトークン（たとえば、nonceが存在する場合の 'unsafe-inline'）を削除する。 次の手順を実行した結果は、一般にlistよりも冗長になりますが、 比較は大幅に単純になります:

  1. listが空である、 または« 'none' »である場合、« 'none' »を返す。

  2. resultを空のソース リストとする。

  3. list内の各expressionについて:

    1. expressionが"'self'"である場合:

      1. originを与えて§ 4.2.1 'self'をoriginのhost-source式に書き換える。 を実行した結果をresultに付加する。

      2. Continueする。

    2. expressionがkeyword-source文法に一致し、 かつnameが "script-src"または"style-src"でない場合、continueする。

    3. 次の文のいずれかが真である場合、Continueする:

    4. expressionがU+002A ASTERISK文字（*）である場合:

      1. « "ftp:", "http:", "https:", "ws:", "wss:" »内の各 schemeについて:

        1. schemeをresultに付加する。

      2. originのschemeと":"を連結したものを resultに付加する。

      3. Continueする。

    5. expressionがscheme-source文法に一致する場合:

      1. expressionが"http:"である場合、"https:"を resultに付加する。

      2. expressionが"ws:"である場合、"wss:"を resultに付加する。

    6. expressionがhost-source文法に一致する場合:

      1. expressionのscheme-partが"http"である場合、 "https://"、expressionのhost-part、 expressionの port-part、および expressionのpath-partを連結した結果をresultに付加する。

      2. expressionのscheme-partが"ws"である場合、 "wss://"、expressionのhost-part、 expressionの port-part、および expressionのpath-partを連結した結果をresultに付加する。

    7. expressionをresultに付加する。

  4. resultが空である または« 'strict-dynamic' »である場合、« 'none' »を返す。

  5. resultを返す。

origin https://example.test/を持つ任意のディレクティブについて:

https: wss: 'none' 'self'
有効ソースリストは"http: wss: https://example.test/"です。なお、"'none'"は唯一のソースでない場合には 効果を持たないため、有効ソースリストには含まれません。

"style-src"について:

http://example.com 'strict-dynamic' 'nonce-abc'
有効ソースリストは"http://example.com 'nonce-abc'"です。これは、"'strict-dynamic'"が "script-src"以外のディレクティブでは無視されるためです。

"script-src"について:

http://example.com 'strict-dynamic' 'nonce-abc'
有効ソースリストは"'strict-dynamic' 'nonce-abc'"です。これは、 "script-src"の場合の"'strict-dynamic'"が、hostおよびschemeのソース式を尊重しないためです。
3.1.5.3. ソース式の類似性

ソース式 (A) は、Aが Bである 場合、またはそれらの文法の関連部分が一致する場合（たとえば、 scheme-source式の場合、それぞれの scheme-partが一方向または他方向に scheme-part matchしなければならない）、 別の ソース式 (B) と source-expression similarであると言われます。

注: この性質は対称です。つまり、 AがBとsource-expression similarである場合、 Bも Aとsource-expression similarになります。

ソース式は、その ソース式のhost-partの最初の文字がU+002A ASTERISK 文字（*）である場合、 ワイルドカードホストを持ちます。

ソース式は、そのソース 式の port-partがU+002A ASTERISK文字（*）である場合、 ワイルドカードポートを持ちます。

  1. Aの文法がBの文法に一致しない場合、 "Not Similar"を返す。

  2. Aがkeyword-source、 nonce-source、または hash-source文法に一致する場合:

    1. AがBである場合、"Similar"を返す。

    2. "Not Similar"を返す。

  3. scheme Aを、存在する場合はAのscheme-part、そうでない場合は nullとする。

  4. scheme Bを、存在する場合はBのscheme-part、そうでない場合は nullとする。

  5. scheme Aがscheme Bにscheme-part matchせず、かつscheme Bが scheme Aにscheme-part matchしない場合、 "Not Similar"を返す。

  6. AまたはBがscheme-source文法に一致する場合、 "Similar"を返す。

  7. host Aを、存在する場合はAのhost-part、そうでない場合は nullとする。

  8. host Bを、存在する場合はBのhost-part、そうでない場合は nullとする。

  9. port Aを、存在する場合はAのport-part、そうでない場合は nullとする。

  10. port Bを、存在する場合はBのport-part、そうでない場合は nullとする。

  11. path Aを、存在する場合はAのpath-part、そうでない場合は nullとする。

  12. path Bを、存在する場合はBのpath-part、そうでない場合は nullとする。

  13. 次のいずれかが真である場合、"Not Similar"を返す:

    1. AとBの両方が ワイルドカードホストを持つが、 host Aがhost Bに対する ASCII大文字小文字不区別一致でない。

    2. AとBのうち高々一方だけが ワイルドカードホストを持ち、 host Aがhost Bに host-part matchせず、かつ host Bが host Aにhost-part match しない。

    3. AもBも ワイルドカードポートを持たず、 port Aが port Bに port-part matchせず、 かつport Bが port Aにport-part match しない。

    4. path Aがpath Bにpath-part matchせず、 かつpath Bが path Aに path-part matchしない。

  14. "Similar"を返す。

A = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA'
B = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA'

AとBはどちらも nonce-source文法に一致し、かつAは Bであるため、AはBに類似しています。 

A = https://inner.example.com/foo/
B = http://*.example.com/foo/bar/

Aはワイルドカードホストを持つため、この場合は "inner"である任意のサブドメインに一致し、そのためAはBに類似しています。

A = http://*.example.com
B = https://inner.example.com:*

AとBのポートは異なりますが、"http"は "http"と、より安全な変種である"https"の両方に一致するため、AとBは 類似しています。

A = http://example.com:80/page1/html
B = https://example.com:443/

AとBは異なるポートを明示的に指定しているため、Aは Bに類似していません。 

A = 'sha256-abc123'
B = 'sha512-cde456'

AとBはどちらも hash-source文法に一致しますが、ハッシュが一致しないため、 Aは Bに一致しません。 

A = http://example.com:80
B = http://example.com:334

この場合、AとBのポートは一致しないため、2つのソースは 類似していません。

A = http://example.com/page.html
B = http://example.com/index.html

2つのソースは、パスが一致しないため類似していません。

残りの 交差アルゴリズムをこの節に移動する。

3.2. 包含

3.2.1. CSPリストの包含

content security policy objectである subsuming policyと、そのorigin (subsuming origin)、およびリストである content security policy objectオブジェクト群 policy listと、そのorigin (origin) が与えられたとき、このアルゴリズムは subsuming policyがpolicy listを 包含する場合に "Subsumes"を返し、そうでない場合に"Does Not Subsume"を返す。

  1. subsuming policyがnullである場合、"Subsumes"を返す。

  2. subsuming policyのdispositionが "report"である場合、 "Subsumes"を返す。

  3. subsuming policyのdirective setが 空である場合、 "Subsumes"を返す。

  4. policy listが空である またはnullである場合、"Does Not Subsume"を返す。

  5. effective policyを、 policy listおよびoriginを与えて § 3.1.1 CSPリストの交差を実行した結果とする。

  6. subsuming policy、 subsuming origin、effective policy、およびoriginを与えて § 3.2.2 ポリシーの包含を実行した結果を返す。

3.2.2. ポリシーの包含

content security policy object A と、 そのorigin (origin A)、および content security policy object B と、 そのorigin (origin B) が与えられたとき、 このアルゴリズムは、AがBを包含する場合に "Subsumes"を返し、そうでない場合に "Does Not Subsume"を返す。

  1. Aのdirective setが 空である場合、 "Subsumes"を返す。

  2. Aのdirective set内の 各directive Aについて:

    1. directive nameをdirective Aのnameとする。

    2. directive nameが"default-src"、 "report-uri"、"report-to"である場合、 continueする。

    3. effective directive Aを、directive nameと Aについての 有効ディレクティブ値とする。

    4. effective directive Bを、directive nameと Bについての 有効ディレクティブ値とする。

    5. effective directive Aがnullである場合、continueする。

    6. effective directive Bがnullである場合、 "Does Not Subsume"を返す。

    7. directive Aのnameが"frame-ancestors"である場合:

      1. effective directive Bが« "'none'" »である場合、continueする。

      2. effective directive Aが« "'none'" »である場合、 "Does Not Subsume"を返す。

      3. effective directive B内の各expression Bについて:

        1. found matchをfalseとする。

        2. effective directive A内の各expression Aについて:

          1. expression Aおよびexpression Bを与えて § 3.2.4 ソース式の 包含が "Subsumes"を返す場合、found matchを trueに設定する。この内側のループを抜ける。

        3. found matchがfalseである場合、 "Does Not Subsume"を返す。

    8. directive Aのnameが"plugin-types"である場合:

      1. effective directive B内の各type Bについて:

        1. effective directive Aがtype Bを含まない場合、 "Does Not Subsume"を返す。

    9. directive Aのnameが"sandbox"である場合:

      1. flags Aを、 effective directive Aを与えてサンドボックス化ディレクティブを 解析する結果とする。

      2. flags Bを、 effective directive Bを与えてサンドボックス化ディレクティブを 解析する結果とする。

      3. flags A内の各flagについて:

        1. flags Bがflagを含まない場合、 "Does Not Subsume"を返す。

      注: ポリシー$A$は、$B$がより 制限的である場合に$B$を包含します。サンドボックスフラグについては、これは $A$によって許可されるすべての権限が$B$によっても許可されなければならないことを意味します。 $B$が$A$に含まれるフラグを省略する場合、その特定の権限について $B$は$A$と少なくとも同程度に制限的ではありません。

    10. directive Aのnameが"disown-opener"である場合、continueする。

    11. そうでない場合:

      1. effective directive A、origin A、directive name、effective directive B、 origin B、およびdirective nameを与えて § 3.2.3 ソースリストの包含を実行した結果が "Does Not Subsume"である場合、 "Does Not Subsume"を返す。

  3. "Subsumes"を返す。

3.2.3. ソースリストの包含

ソースリスト A と、そのorigin (origin A) および文字列 (directive A)、 ソースリスト B と、そのorigin (origin B) および文字列 (directive B) が与えられたとき、この アルゴリズムは、AがBを包含する場合に "Subsumes"を返し、そうでない場合に "Does Not Subsume"を返す。

directiveは、与えられた ソース式がその valueに 含まれている場合、そのソース式を 含む。

  1. directive Aがdirective Bに対するASCII大文字小文字不区別一致でない場合、 "Does Not Subsume"を返す。

  2. Aが空である、またはBがnoneである場合、 "Subsumes"を返す。

  3. Bが空である、またはAがnoneである場合、 "Does Not Subsume"を返す。

  4. directive Bが"script-src"であり、かつBが "strict-dynamic"という keyword-source式を 含むが、 Aはそれを含まない場合、 "Does Not Subsume"を返す。

  5. directive Bが"script-src"または"style-src"である場合:

    1. Bが"unsafe-eval"という keyword-source式を 含むが、 Aはそれを含まない場合、"Does Not Subsume"を返す。

    2. Bが "unsafe-hashed-attributes"という keyword-source式を 含むが、Aはそれを含まない場合、 "Does Not Subsume"を返す。

    3. type Bを、directive Bが "script-src"である場合は"script"、そうでない場合は "style"とする。 同様に、type Aを、directive Aが "script-src"である場合は"script"、そうでない場合は "style"とする。

    4. Bとtype Bを与えたときにContent Security Policy 3 § 6.7.3.2 Does a source list allow all inline behavior for type?が"Allows"を返すが、 Aとtype Aを与えたときには "Does Not Allow"を返す場合、 "Does Not Subsume"を返す。

  6. list Aおよびlist Bを空リストとする。

  7. A内の各expression Aについて:

    1. expression Aが"self"である場合、origin Aを与えて § 4.2.1 'self'をoriginのhost-source式に書き換える。から返された host-sourceを list Aに付加する。

    2. expression AがU+002A ASTERISK文字（*）に一致する場合、 次のscheme-source 式をlist Aに付加する: "ftp:"、"http:"、"https:"、 "ws:"、"wss:"、およびorigin Aのscheme。

      1. directive Aが"img-src"または "media-src"のいずれかである場合、 "data:"という scheme-source 式をlist Aに付加する。

      2. directive Aが"media-src"である場合、 "blob:"というscheme-source 式をlist Aに付加する。

      3. 次のexpression Aへ Continueする。

    3. expression Aがkeyword-source文法に一致しない場合、 expression Aをlist Aに付加する。

  8. B内の各expression Bについて:

    1. expression Bが"self"である場合、origin Bを与えて § 4.2.1 'self'をoriginのhost-source式に書き換える。から返された host-sourceを list Bに付加する。

    2. expression BがU+002A ASTERISK文字（*）に一致する場合、 次のscheme-source 式をlist Bに付加する: "ftp:"、"http:"、"https:"、 "ws:"、"wss:"、およびorigin Bのscheme。

      1. directive Bが"img-src"または "media-src"のいずれかである場合、 "data:"という scheme-source 式をlist Bに付加する。

      2. directive Bが"media-src"である場合、 "blob:"というscheme-source 式をlist Bに付加する。

      3. 次のexpression Bへ Continueする。

    3. expression Bがkeyword-source文法に一致しない場合、 expression Bをlist Bに付加する。

  9. list Bが空である場合、"Subsumes"を返す。

  10. list Aが空である場合、"Does Not Subsume"を返す。

  11. list B内の各expression Bについて:

    1. expression Bがhash-source文法、または nonce-source文法に一致する場合、 directive Aが"script-src"または "style-src"でない限り、次の式へ continueする。

    2. found matchをfalseとする。

    3. list A内の各expression Aについて:

      1. expression Aおよび expression Bを与えて§ 3.2.4 ソース式の 包含が"Subsumes"を返す場合、found matchを trueに設定する。 この内側のループを抜ける。

    4. found matchがfalseである場合、 "Does Not Subsume"を返す。

  12. "Subsumes"を返す。

directive Aおよびdirective Bを"script-src"とする。 次の例を考える: 
A = "http://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com"

Bはhash-source式を許可しませんが、 その値が A内に見つかるため、AはBを包含します。ただし、 BがAを包含することは 真ではありません。 

A = "https://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com"

この場合、"https://example.com"は"http://example.com"を包含しないため、 AはBを包含しません。 

A = "http://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com 'unsafe-inline'"

Bはすべてのインライン動作を許可するが、 Aは許可しないため、Aは Bを包含しません。 

A = "http://example.com 'sha256-xzi4zkCjuC8' 'strict-dynamic'"
B = "http://example.com 'unsafe-inline' 'strict-dynamic'"

AもBもすべてのインライン動作を許可しません。 この場合、Aは Bを包含します。

3.2.4. ソース式の包含

2つのソース式 AおよびBが与えられたとき、 このアルゴリズムは、Aが Bを包含する場合に "Subsumes"を返し、そうでない場合に "Does Not Subsume"を返す。

  1. アサート: AもBもkeyword-source文法に一致しない。

  2. AとBの両方がhost-sourceまたは scheme-source文法のいずれかに一致する場合:

    1. Aの scheme-part（または Aが scheme-partを含まない場合は null）および Bのscheme-part（または Bがscheme-partを 含まない場合はnull）を与えて、 Content Security Policy 3 § 6.7.2.9 scheme-part matchingが "Does Not Match"を返す場合、 "Does Not Subsume"を返す。

    2. AまたはBがscheme-source文法に一致する場合:

      1. Aがscheme-source 文法に一致する場合、"Subsumes"を返す。 そうでない場合、"Does Not Subsume"を返す。

    3. Bがwildcard hostを持つ場合:

      1. Aがwildcard hostを持たない場合、 "Does not Subsume"を返す。

      2. remaining host Bを、Bの host-partから先頭の ("*.")を削除した結果とする。

      3. Aの host-partおよび remaining host Bを与えて、 Content Security Policy 3 § 6.7.2.10 host-part matchingが "Does Not Match"を返す場合、"Does Not Subsume"を返す。

    4. Bがwildcard hostを持たず、かつ Aのhost-partおよび Bのhost-partを与えて Content Security Policy 3 § 6.7.2.10 host-part matchingが "Does Not Match"を返す場合、 "Does Not Subsume"を返す。

    5. Bがwildcard portを持つがAは wildcard portを持たない場合、"Does Not Subsume"を返す。

    6. Bがwildcard portを持たず、かつ Aのport-part（または Aが port-partを含まない場合は null）および Bのport-part（または Bが port-partを含まない場合は null）を与えて Content Security Policy 3 § 6.7.2.11 port-part matchingが "Does Not Match"を返す場合、 "Does Not Subsume"を返す。

    7. Aのpath-part （またはAがpath-partを含まない場合は null）および Bの path-part（または Bが path-partを含まない場合は null）を与えて Content Security Policy 3 § 6.7.2.12 path-part matchingが "Does Not Match"を返す場合、 "Does Not Subsume"を返す。

    8. "Subsumes"を返す。

  3. AとBの両方がhash-source文法に一致する場合:

    1. Aが Bである場合、 "Subsumes"を返す。そうでない場合、 "Does Not Subsume"を返す。

  4. AとBの両方がnonce-source文法に一致する場合:

    1. "Subsumes"を返す。

    注: Nonceソースの照合は、 悪意ある埋め込み元が§ 6.1 ポリシー漏えいで説明される攻撃によってnonce値を総当たりできないように、 値に依存しません。

  5. "Does Not Subsume"を返す。

nonceおよびハッシュの包含は、 （'unsafe-inline'と組み合わせた'self'や'*'のような）より許容的なソースが 論理的にそれらを包含することを考慮するよう更新されるべきです。

4. アルゴリズム

4.1. requestに対するresponseはrequiredCSPによってブロックされるか？

response (response)、request (request)、および直列化されたCSPまたはnull (requiredCSP) が与えられたとき、このアルゴリズムは適宜 "Allowed"または"Blocked"を返す:

  1. requiredCSPがnullである場合、"Allowed"を返す。

  2. required policyを、requiredCSPを "enforce"として解析した結果とする。

  3. responseおよび requestに対して§ 4.2 responseはrequestからのポリシーの 一括強制を許可するか？アルゴリズムを実行したときに"Allowed"を返す場合、 "Allowed"を返す。

  4. required policy、responseのurlのorigin、 responseのContent Security Policiesを解析した結果、 およびresponseのurlのoriginに対して § 3.2.1 CSPリストの包含アルゴリズムを実行したときに "Subsumes"を返す場合、"Allowed"を返す。

  5. "Blocked"を返す。

4.2. responseはrequestからのポリシーの一括強制を許可するか？

response (response) と、request (request) が与えられたとき、このアルゴリズムは、前者が後者に任意のポリシーを 強制することを許可する場合は "Allowed"を返し、そうでない場合は "Not Allowed"を返す:

  1. responseのurlのschemeがlocal schemeである場合、"Allowed"を返す。

    注: local scheme応答はすでに埋め込み元からポリシーを継承するため、この埋め込みメカニズムを介して 埋め込み元がそのポリシーを厳格化することを許可します。

  2. responseのheader listが `Allow-CSP-From` という名前のヘッダー (header) を持つ場合:

    1. headerの値が"*"である場合、"Allowed"を返す。

    2. requestのoriginを直列化して UTF-8エンコードしたものがheaderの値である場合、 "Allowed"を返す。

  3. "Not Allowed"を返す。

4.2.1. 'self'をoriginのhost-source式に書き換える。

origin (origin) が与えられたとき、このアルゴリズムは、そのoriginに対して 'self'と同じ効果を持つ host-source式を返す:

  1. originがopaque originである場合、空文字列を返す。

  2. originのASCII直列化を返す。

5. セキュリティに関する考慮事項

5.1. 脅威モデル

この提案は、文書が埋め込む子フレーム内で使用されるコンテンツを、その文書が制御できるようにすることを 目的としています。フレームは一般にそれ自体がセキュリティ境界と見なされ、 意図的にクロスオリジンアクセスを制限しているため、その境界を弱めないようにする必要があります。

したがって、私たちの目標は次のとおりです:

この提案は、CSPのframe-ancestorsやX-Frame-Optionsのような既存の 分離メカニズムに取って代わることを意図しておらず、また iframe 要素がすでに表すものを超える保護を、埋め込まれる側に提供するものでもありません。

5.2. ポリシー強制

埋め込まれる文書は、提案されたContent Security Policyを慎重に評価すべきであり、 埋め込み元が提案する任意のポリシーを単に反映すべきではありません。そうすると、巧妙な攻撃者が、 そのWebサイト自身の保護に不可欠なコードの一部を選択的に無効化できる可能性があります。

特に、埋め込まれることを想定していない文書は、そのようなリクエストに対して、 適切なframe-ancestors ディレクティブを含むContent Security Policyで応答し続けるべきです。

5.3. ヘッダーリフレクション

サーバーは、 `Sec-Required-CSP` ヘッダーを `Content-Security-Policy` レスポンスヘッダーへ盲目的に反映することに注意すべきです。課されたポリシーが結果として得られる コンテキストを予期しない方法で制限したり、サーバーが本来適用するポリシーよりも弱かったりする 可能性があるためです。

代わりに、開発者には、信頼済みオリジンについて `Allow-CSP-From` ヘッダーを配信することで、受信したポリシーを受け入れる前に評価することが推奨されます。 これにより、ページが適用したいポリシーが適用される一方で、必要なポリシーがその上に重ねられます。 複数のポリシーは制限を厳しくすることしかできないため、これによりサーバーのポリシーが堅固な 基準保護として維持されることが保証されます。

5.4. ヘッダー長

この機能により、埋め込み元はクロスオリジンの埋め込み文書リクエストについて `Sec-Required-CSP` HTTPヘッダーの値を制御できます。サーバーがHTTPヘッダーの長さに制限を強制している場合、 これはネットワークエラーを引き起こす可能性があります。これは、攻撃者がキャッシュ無効化を強制するために 悪用できる可能性があります。詳しくは、 https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events を参照してください。このため、有効なcsp属性の最大長を4 KBに制限します。

6. プライバシーに関する考慮事項

6.1. ポリシー漏えい

強制メカニズムにより、悪意ある埋め込み元が制約を総当たりすることで、ページのポリシーを クロスオリジンで読み取れるようになります。ポリシーに秘密トークンやユーザー名が含まれている場合、 これはページやそのページを読み込むユーザーに関する興味深いデータを漏えいさせる可能性があります。

ここでも最善の防御策は、適切なframe-ancestorsディレクティブを介して、 与えられたリソースを埋め込めるコンテキストを制御することです。

6.2. データ流出

この機能により、埋め込み元は `Sec-Required-CSP` HTTPヘッダーを介して、サードパーティエンドポイントへ情報を送信できます。これは、 HTTPリクエスト自体（GETパラメーターなど）でトンネリングできない情報を公開するようには 見えません。また、埋め込み元は適切なchild-srcディレクティブを持つ Content Security Policyを強制することにより、そのようなリクエストを送信できるエンドポイントを 引き続き制御できます。

7. 作成に関する考慮事項

7.1. 'self'を要求する

required CSPを処理する際、キーワード'self'は、 ポリシーを要求した文書のoriginではなく、child navigableに読み込まれるURLの originを指します。

MegaCorp Inc.は、 https://example.com/page.htmlにある自社ページで、'self'を含むポリシーを要求します: 
<iframe src="https://advertisements-r-us.example.com/ad1.cfm"
        csp="script-src 'self'">
</iframe>

返されたCSPが次の場合:

Content-Security-Policy: script-src 'self'

この iframe 要素は読み込まれます。

しかし、返されたCSPが次の場合:

Content-Security-Policy: script-src "https://example.com/"

この iframe 要素は読み込まれません。

8. IANAに関する考慮事項

恒久的メッセージヘッダーフィールドレジストリは、 `Sec-Required-CSP` ヘッダーについて、次の登録で更新されるべきです: [RFC3864]

ヘッダーフィールド名

Sec-Required-CSP

適用可能なプロトコル

http

ステータス

standard

著者/変更管理者

W3C

仕様文書

この仕様（§ 2.2 Sec-Required-CSP HTTPリクエスト ヘッダーを参照）

同様に、レジストリは `Allow-CSP-From` ヘッダーについて、次の登録で更新されるべきです: [RFC3864]

ヘッダーフィールド名

Allow-CSP-From

適用可能なプロトコル

http

ステータス

standard

著者/変更管理者

W3C

仕様文書

この仕様（§ 2.3 Allow-CSP-From HTTPレスポンス ヘッダーを参照）

適合性

文書の 慣例

適合要件は、記述的な表明と 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"で示されます。 次のようになります:

注: これは参考注です。

適合 アルゴリズム

アルゴリズムの一部として命令形で表現された要件 （たとえば“先頭の空白文字をすべて取り除く”や “falseを返してこれらの手順を中止する”など）は、 そのアルゴリズムを導入する際に用いられるキーワード （“must”、“should”、“may”など）の意味で解釈されるものとします。

アルゴリズムまたは特定の手順として表現された適合要件は、 最終結果が同等である限り、 どのような方法で実装してもかまいません。 特に、この仕様で定義されるアルゴリズムは 理解しやすいことを意図しており、 高性能であることを意図していません。 実装者には最適化が推奨されます。

索引

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

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

参考文献

規範参考文献

[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. 2026年5月5日. WD. URL: https://www.w3.org/TR/CSP3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 2024年3月12日. WD. URL: https://www.w3.org/TR/css-values-4/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[ENCODING]
Anne van Kesteren. Encoding Standard. Living Standard. URL: https://encoding.spec.whatwg.org/
[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. RFCで要件レベルを示すために用いる キーワード. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. メッセージ ヘッダーフィールドの登録手順. 2004年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC5234]
D. Crocker, Ed.; P. Overell. 構文仕様のための拡張 BNF: ABNF. 2008年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

IDL索引

partial interface HTMLIFrameElement {
  [CEReactions] attribute DOMString csp;
};

イシュー索引

これをすべてのHTMLにアップストリームする。↵
これをアップストリームする。↵
読者にこの演習をさせるべきではありません。また、単一のポリシーとして表現できない交差を どのように扱うか（たとえばポリシーのリストを維持することによって）についても指針を提供すべきです。 ↵
ソースリストではないものを扱うために、この定義を拡張する必要があります。 また、より精密にすべきであり、おそらくdirective nameに対して確認できる“source list directive”のような用語を定義することによって実現できます。↵
残りの交差アルゴリズムをこの節に移動する。↵
nonceおよびハッシュの包含は、（'unsafe-inline'と組み合わせた'self'や'*'のような） より許容的なソースがそれらを論理的に包含することを考慮するよう更新されるべきです。↵
⚠MDN

HTMLIFrameElement/csp

In only one current engine.

FirefoxNoneSafariNoneChrome61+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?