iframe 要素

4.7.2 iframe 要素

カテゴリー:
フロー・コンテント
フレージング・コンテント
エンベッディッド・コンテント
インタラクティブ・コンテント
パルパブル・コンテント
この要素を使うことができるコンテキスト:
エンベッディッド・コンテントが期待される場所
コンテントモデル:
本文に書かれた要件に準拠するテキスト
コンテント属性:
グローバル属性
src - リソースのアドレス
srcdoc - iframe にレンダリングするドキュメント
name - ネストされるブラウジングコンテキストの名前
sandbox - ネストされるコンテンツのセキュリティ規則
width - 水平方向の寸法
height - 垂直方向の寸法
text/html におけるタグの省略:
どちらのタグも省略できません。
指定可能な ARIA role 属性 の値:
application, document, img, presentation
指定可能な ARIA ステートとプロパティ属性:
グローバル aria-* 属性
許可ロールに該当する aria-* 属性
DOM インタフェース:
interface HTMLIFrameElement : HTMLElement {
           attribute DOMString src;
           attribute DOMString srcdoc;
           attribute DOMString name;
  [PutForwards=value] readonly attribute DOMSettableTokenList sandbox;
           attribute DOMString width;
           attribute DOMString height;
  readonly attribute Document? contentDocument;
  readonly attribute WindowProxy? contentWindow;
};

iframe 要素は、ネストされたブラウジングコンテキスト表します。

src 属性には、ネストされるブラウジングコンテキストに入れるページのアドレスを指定します。この属性が存在するなら、 それは潜在的にスペースで囲まれた空でない妥当な URL でなければいけません。

srcdoc 属性には、ネストされるブラウジングコンテキストに入れるページのコンテンツを指定します。この属性の値は、iframe srcdoc ドキュメントのソースです。

HTML ドキュメントiframe 要素では、srcdoc 属性が存在するなら、それは、次に示す構文上のコンポーネントから構成された HTML 構文を使った値を持たなければいけません。これは、次に示す順番でなければいけません:

  1. 任意の数のコメントスペース文字
  2. オプションで、DOCTYPE
  3. 任意の数のコメントスペース文字
  4. ルート要素。html 要素が相当します。
  5. 任意の数のコメントスペース文字

XML ドキュメントiframe 要素では、srcdoc 属性を指定するなら、その値は、XML 仕様にある document と表記された生成規則に一致しなければいけません。 [XML]

HTML 構文では、ウェブ制作者は、""" (U+0022) を使ってこの属性のコンテンツを囲み、すべての """ (U+0022) と U+0026 AMPERSAND (&) 文字をエスケープし、sandbox 属性を指定し、必ず組み込むコンテンツが安全になるようにすることを忘れないようにする必要があります。

XHTML 構文の制限により、XML では、"<" (U+003C) 文字もエスケープする必要があります。属性値の正規化を避けるために、いくつかの XML のホワイトスペース文字、とりわけ "tab" (U+0009), LF" (U+000A), "CR" (U+000D) も、エスケープする必要があります。 [XML]

src 属性と srcdoc 属性が両方とも一緒に指定された場合、srcdoc が優先されます。これによって、ウェブ制作者は、srcdoc 属性をサポートしていない古いユーザーエージェントに対して、フォールバックの URL を提供することができるようになります。


iframe 要素がドキュメントに挿入されるとき、ユーザーエージェントは、ネストされたブラウジングコンテキストを生成しなければいけません。その後に "初めて" iframe の属性を処理しなければいけません。

iframe 要素がドキュメントから削除されるとき、ユーザーエージェントは、ネストされたブラウジングコンテキスト破棄しなければいけません。

これによって、unload イベントが発生することはありません(ネストされたブラウジングコンテキストとその Document は、アンロードされるのではなく、破棄されるからです)。

ネストされたブラウジングコンテキストを持った iframe 要素に srcdoc 属性がセットされたり変更されたり削除されたら、ユーザーエージェントは iframe の属性を処理しなければいけません。

同様に、ネストされたブラウジングコンテキストを持つものの、srcdoc 属性が指定されていない iframe 要素に、src 属性がセットされたり変更されたり削除されたら、ユーザーエージェントは iframe の属性を処理しなければいけません。

ユーザーエージェントが iframe の属性を処理することになったら、次のリストのうち最初の適切な手順を実行しなければいけません:

srcdoc 属性が指定されている場合

該当の要素の子ブラウジング・コンテキストを、Content-Typetext/html で、URL が about:srcdoc で、データがこの属性の値から構成されるリソースへナビゲートします。結果として得られた Documentiframe srcdoc ドキュメントと見なされなければいけません。

src 属性が指定されておらず、ユーザーエージェントが "初めて" その iframe の属性を処理する場合

iframe load イベント手順を実行するタスクをキューイングします。

このタスクタスクソースDOM マニピュレーション・タスクソースです。

上記以外の場合
  1. src の値がない、または、その値が空文字列なら、url を、文字列 "about:blank" とします。

    そうでなければ、src 属性の値を iframe 要素に対して解決します。

    それが成功しなかったら、url を "about:blank" とします。そうでなければ、url を、結果として得られた絶対 URL とします。

  2. フラグメント識別子を除いて、アクティブドキュメントアドレスurl と同じとなる 祖先ブラウジングコンテキストが存在すれば、これらの手順を中止します。

  3. この要素の子ブラウジングコンテキストurlナビゲートします。

iframe の属性を処理するアルゴリズムでユーザーエージェントの要件となるあらゆるナビゲーションは、明示的な自己ナビゲーション・オーバーライドとして完了されなければいけません。これは、ソース・ブラウジングコンテキストとして iframe 要素のドキュメントのブラウジングコンテキストを使います。

さらに、このようなナビゲーションの前の該当の要素の子ブラウジングコンテキストアクティブドキュメントが、新たなナビゲーションの際に完全にロードされていなかったら、そのナビゲーション置換有効で完了されなければいけません。

同様に、iframe の属性の処理アルゴリズムが呼び出されたときに子ブラウジングコンテキストセッション履歴Document が一つしかなく、そして、それが、その子ブラウジングコンテキストが生成されたときに生成された about:blank Document だったなら、そのアルゴリズムでのユーザーエージェントに要求されるあらゆるナビゲーションは、置換有効で完了されなければいけません。

iframe の中にある Document完全にロード済みとしてマークされているとき、ユーザーエージェントは、iframe load イベント手順を同期的に実行しなければいけません。

load イベントは、iframe 要素が生成されたとき、他のデータがその中に何もロードされない場合にも、発生します。

それぞれの Document は、iframe load in progress フラグと mute iframe load フラグを持ちます。Document が生成されるとき、これらのフラグはその Document にはセットされてはいけません。

iframe load イベント手順は次のとおりです:

  1. child document を、iframe 要素のネストされたブラウジングコンテキストアクティブドキュメントとします。

  2. child documentmute iframe load がセットされているなら、これらの手順を中止します。

  3. child documentiframe load in progress フラグをセットします。

  4. iframe 要素で load という名前のシンプルなイベントを発出します。

  5. child documentiframe load in progress フラグを解除します。

これは、スクリプトと組み合わせれば、ローカルネットワークの HTTP サーバーの URL 空間の探索に使えてしまいます。ユーザーエージェントは、クロスオリジンのアクセス制御ポリシーを実装することができます。これは前述のポリシーよりも厳格ですので、この攻撃を和らげることはできるのですが、残念なことに、こういったポリシーは、通常は、既存のウェブコンテンツと互換性がありません。

iframeブラウジングコンテキストアクティブドキュメントロード後のタスクの準備が整っていないとき、そして、iframe にある何かが iframeブラウジングコンテキストアクティブドキュメントload イベントを遅らせているとき、そして、iframeブラウジングコンテキストload イベント遅延モードにあるとき、その iframe は、そのドキュメントの load イベントを遅らせなければいけません。

もし、load イベントを処理する間に、iframeブラウジングコンテキストが再びナビゲートされたら、それは、さらに load イベントを遅らせるでしょう。

もし、この要素が生成されたときに srcdoc 属性がセットされていない、かつ、src 属性もセットされていないか、その値が解決できなかった、のいずれかなら、そのブラジングコンテキストは、初期の about:blank ページのままとなります。

ユーザーがナビゲートしてこのページから離れたなら、その iframe に対応する WindowProxy オブジェクトは、新たな Document オブジェクトに対して、新たな Window オブジェクトをプロキシしますが、src 属性は変わりません。


name 属性が存在するなら、それは、妥当なブラウジングコンテキスト名でなければいけません。指定された値は、ネストされたブラウジング・コンテキストを名付けるために使われます。ブラウジングコンテキストが生成されたとき、この属性が存在すれば、そのブラウジングコンテキスト名は、この属性の値となるようセットされなければいけません。そうでなければ、そのブラウジングコンテキスト名は空文字列となるようセットされなければいけません。

name 属性がセットされたら常に、ネストされたブラウジングコンテキスト名前は、新しい値に変更されなければいけません。この属性が削除されたら、ブラウジングコンテキスト名は空文字となるようセットされなければいけません。


sandbox 属性を指定すると、その iframe によって組み込まれたコンテンツ上に制限を追加することができます。この値は、ユニークなスペース区切りトークン非順序セットでなければいけません。大文字と小文字は区別されません。指定可能な値は、allow-forms, allow-pointer-lock, allow-popups, allow-same-origin, allow-scripts, allow-top-navigation です。

この属性がセットされたら、そのコンテンツは、固有のオリジンからのものであるととして扱われ、フォームとスクリプト、そして問題となりそうな API は無効にされ、別のブラウジングコンテキストを指しているリンクは抑制され、プラグインはセキュアにされます。allow-same-origin キーワードを指定すると、そのコンテンツは、強制的に固有なオリジンからのものと見なされず、同じオリジンからのものと扱われるようになります。allow-top-navigation キーワードを指定すると、そのコンテンツからトップレベル・ブラウジングコンテキストナビゲートできるようにします。allow-forms, allow-pointer-lock, allow-popups, allow-scripts キーワードを指定すると、それぞれ、フォーム、pointer lock API、ポップアップ、スクリプトを再び有効にすることができます。 [POINTERLOCK]

組み込まれたページが iframe を含むページとして同一オリジンを持つとき、allow-scriptsallow-same-origin の両方をセットしたとしても、その組み込まれたページは、単に sandbox 属性を削除し、自身をリロードすることができるようになるだけです。結局のところ、そのサンドボックスから効率的に脱獄できるようになるだけです。

これらのフラグは、iframeネストされたブラウジングコンテキストナビゲートされるときだけに効力を持ちます。これらを削除したり、sandbox 属性をまるごと削除したとしても、すでにロードされたページには何も影響を与えません。

悪意のあるファイルが iframe 要素を含むファイルと同じサーバーから提供されるとは限りません。ユーザーに iframe を使わずとも悪意のあるコンテンツに直接的に訪問するよう誘導できるとアタッカーが気づくことができれば、悪意のあるコンテンツをサンドボックス化しても、あまり大きな助けにはなりません。悪意のある HTML コンテンツによって引き起こされうるダメージを抑えるために、それは別の専用のドメインから提供されるべきです。異なるドメインを使えば、確実に、そのファイルの中のスクリプトがサイトを攻撃できないようにすることができます。たとえ、ユーザーがそれらのページに直接的に訪れるよう仕掛けられたとしても、sandbox 属性の保護がなくてもです。

sandbox 属性を伴う iframe 要素がネストされたブラウジングコンテキストを生成してもらうとき(初期の about:blank Document が生成される前)、そして、iframe 要素がネストされたブラウジングコンテキストを持つ間に sandbox 属性がセットまたは変更されるとき、ユーザーエージェントはサンドボックス化指示をパースしなければいけません。その際には、この属性の値を input として、そして、iframe 要素のネストされたブラウジングコンテキストiframe サンドボックス化フラグセットを出力として使います。

iframe 要素がネストされたブラウジングコンテキストを持つ間にその sandbox 属性が削除されたら、ユーザーエージェントは、出力として、その iframe 要素のネストされたブラウジングコンテキストiframe サンドボックス化フラグセットを空にしなければいけません。

この例では、完全に不明で、敵対の可能性があり、ユーザーが提供した HTML コンテンツがページに組み込まれています。これは別のドメインから提供されているため、それは、すべての通常のクロスサイト制限の影響を受けます。さらに、組み込まれたページのスクリプトとプラグインとフォームは無効化され、それ自身ではない他のフレームやウィンドウをナビゲートすることはできません(または、それ自身が組み込んでいるあらゆるフレームやウィンドウ)。

<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="http://usercontent.example.net/getusercontent.cgi?id=12193"></iframe>

別のドメインを使う点が重要です。こうすることで、ユーザーを危険にさらすようなページへユーザーが直接的に訪問するようアタッカーが誘導したとしても、そのページは、そのページのあらゆる攻撃に対してユーザーを無防備にしてしまうであろうそのサイトのオリジンのコンテキストの中で実行されることはありません。

この例では、他のサイトからのガジェットが組み込まれています。このガジェットはスクリプティングとフォームが有効になっており、オリジン・サンドボックス制限が適用されますが、そのガジェットは、そのもととなるサーバと通信することができます。それでもなお、サンドボックスは役に立っているのです。それは、プラグインとポップアップを無効にするからです。ゆえに、ユーザーがマルウェアや他の厄介者にさらされるリスクを低減します。

<iframe sandbox="allow-same-origin allow-forms allow-scripts"
        src="http://maps.example.com/embedded.html"></iframe>

ファイル A が次のコードを含んでいるとします:

<iframe sandbox="allow-same-origin allow-forms" src=B></iframe>

また、ファイル B も iframe を含んでいるとします:

<iframe sandbox="allow-scripts" src=C></iframe>

さらに、ファイル C がリンクを含んでいるとします:

<a href=D>Link</a>

この例では、すべてのファイルが text/html として提供されるとします。

このシナリオでは、ページ C はすべてのサンドボックス化フラグがセットされます。スクリプトは無効になります。なぜなら、A の iframe のスクリプトは無効にされているからです。そして、これは、B の iframe にセットされた allow-scripts キーワードより優先されます。フォームも無効になります。なぜなら、内部の iframe (B の中) には allow-forms キーワードがセットされていないからです。

では、次に、A からスクリプトを使って A と B の sandbox 属性をすべて削除したとしましょう。すると、すぐには何も変化は起こりません。もし、ユーザーが C のリンクをクリックしたら、B の iframe にページ D がロードされますが、ページ D は、B の iframeallow-same-originallow-forms キーワードがセットされているかのように振る舞います。なぜなら、ページ B は、ロードされたときは、A の iframeネストされたブラウジングコンテキストの状態だったからです。

一般的には、動的に sandbox 属性を変更したり削除したりするのは賢明ではありません。なぜなら、そうしたとしても、何が許可され、何が許可されないのかについて判断するのは、相当に難しくなるからです。


iframe 要素は、組込コンテンツが特定の寸法を持つ場合のためにディメンジョン属性をサポートします(例:広告ユニットが明瞭な寸法を持つ)。

iframe 要素は、決してフォールバック・コンテントを持ちません。なぜなら、iframe 要素は、指定された初期コンテンツが成功裏に使われたかどうかにかかわらず、常に、ネストされたブラウジングコンテキストを生成するからです。


iframe 要素の子孫は何も表しません。(iframe 要素をサポートしない古いユーザーエージェントでは、そのコンテンツは、フォール・バックコンテントとして動作することができるマークアップとしてパースされるでしょう。)

HTML ドキュメントで使うとき、iframe 要素に許されるコンテントモデルはテキストです。ただし、context 要素に iframe 要素を、input にテキスト・コンテンツを引き渡して HTML フラグメント・パース・アルゴリズムを呼び出した結果が、すべてフレージング・コンテントとなるノードのリストとなり、パース・エラーが発生せず、そのリストに、または、そのリストの要素の子孫に script 要素が一切なく、そして、そのリストのすべての要素(それらの子孫も含む)が、それら自身、準拠しなければならない点は除きます。

iframe 要素は、XML ドキュメントでは、空でなければいけません。

HTML パーサーは、iframe 要素内のマークアップをテキストとして扱います。


IDL 属性 src, srcdoc, name, sandbox は、それぞれ同じ名前の対応するコンテント属性を反映しなければいけません。

contentDocument IDL 属性は、iframe 要素のネストされたブラウジングコンテキストがあり、そのeffective script originincumbent settings objectによって指定されたeffective script origin同一オリジンならば、そのアクティブドキュメントDocument オブジェクトを返さなければいけません。そうでなければ、null を返さなければいけません。

The contentWindow IDL 属性は、iframe 要素のネストされたブラウジングコンテキストがあれば、その WindowProxy オブジェクトを返さなければいけません。なければ、null を返さなければいけません。

この例では、iframe を使って、広告仲介業者からの広告をページに組み込んでいます:

<iframe src="http://ads.example.com/?customerid=923513721&amp;format=banner"
        width="468" height="60"></iframe>

※ 原文:http://www.w3.org/TR/2014/REC-html5-20141028/embedded-content-0.html#the-iframe-element