埋め込みコンテンツは、他のページやサイトのコンテンツを共有しながら、ユーザーをサイトに留めておく最善の方法です。埋め込みツイートのように小さいもので、Twitter のスタイルと形式で表示されます。埋め込みコンテンツは、サイトに埋め込まれた完全に別のサイト（訪問者がサイトを離れることなく購入できる埋め込みの Shopify ストアなど）にまで及ぶ場合があります。
コンテンツを埋め込む際に、サイトのセキュリティを維持することがこれまで以上に重要になっています。
デベロッパーがウェブサイトにコンテンツを埋め込む方法はいくつかあります。最も一般的な手法は <iframe> を使用する方法です。これにより、URL だけで任意のコンテンツをサイトに埋め込むことができます。sandbox 属性を追加して iframe のセキュリティを高めることは、すでに可能です。
または、提案されている HTML 要素を使用することもできます。
<fencedframe>は、サードパーティ コンテンツを埋め込むプライバシー保護の方法として提案されています。<portal>は、よりシームレスなページ遷移を実現するために提案されています。
埋め込みコンテンツのセキュリティを強化する方法については、以下をご覧ください。
iframe で埋め込む
iframe は、連絡先ページへの地図やフォームの追加、広告の表示など、あらゆる種類のユースケースに使用できます。
<iframe src="https://example.com/maps"></iframe>
各 iframe には、独自のセッション履歴とドキュメントを持つ独自のブラウジング コンテキストがあります。iframe が埋め込まれているコンテキストは、親ブラウジング コンテキストと呼ばれます。
iframe に表示されるサードパーティ コンテンツは、postMessage() を介して親サイトとやり取りできます。これにより、デベロッパーはブラウジング コンテキスト間で任意の値を送信できます。メッセージ受信側は、イベント リスナー onmessage を使用して値を受信できます。
// inside iframe
window.parent.postMessage("ping", "https://example.com");
// window
window.addEventListener("message", (event) => {
console.log(event.data);
})
sandbox 属性によるセキュリティの追加
悪意のあるコンテンツが iframe にデプロイされている場合、意図しないアクション（JavaScript の実行やフォームの送信など）が実行される可能性があります。これを回避するため、sandbox 属性は iframe で実行可能な API を制限し、有害な可能性のある機能を無効にします。
<iframe src="https://example.com" sandbox></iframe>
サンドボックスでは、埋め込みコンテンツにとって重要な特定の API を使用できない場合があります。無効な API を許可するには、サンドボックス属性に引数を明示的に追加します。
<iframe sandbox="allow-forms" src="https://example.com"></iframe>
sandbox 仕様には、allow-forms、allow-same-origin、allow-popups など、さまざまな値が指定できます。
権限に関するポリシー
ウェブ向けの機能がますます強力になるにつれ、それらのすべての権限を管理するために権限ポリシーが作成されました。権限ポリシーは、親サイトと iframe コンテンツに適用できます。親サイトに付与された権限は、allow 属性を使用して iframe にも付与できます。
<iframe src="https://example.com" allow="fullscreen"></iframe>
フェンス付きフレームで埋め込む
フェンス付きフレーム（<fencedframe>）は、iframe と同様に、埋め込みコンテンツ用に提案された HTML 要素です。iframe とは異なり、フェンス付きフレームは、埋め込みコンテキストとの通信を制限し、フレームが埋め込みコンテキストと共有することなく、クロスサイト データにアクセスできるようにします。同様に、親ページのファースト パーティ データは、フェンスされたフレームと共有できません。
<fencedframe src="https://3rd.party.example"></fencedframe>
フェンスド フレームは、トップレベル サイトがデータをパーティショニングすることを提案するプライバシー サンドボックスの提案です。プライバシー サンドボックスの提案の多くは、サードパーティ Cookie やその他のトラッキング メカニズムを使用せずに、クロスサイトのユースケースに対応することを目的としています。特定のプライバシー サンドボックス API では、フェンス付きフレーム内にレンダリングするようにドキュメントを選択する必要があります。
たとえば、FLEDGE API 広告オークションの落札者にフェンス付きフレームが作成されます。FLEDGE API は、フェンスで囲まれたフレーム内にレンダリングできる不透明なソース（ロケーションに依存しない URN スキーム）を提供します。不透明なソースを使用すると、サイト所有者に広告ソースの URL を開示せずに、サイトにコンテンツを表示できます。
<fencedframe src="urn:uuid:c36973b5-e5d9-de59-e4c4-364f137b3c7a"></fencedframe>
最終的には、フェンス付きフレームが iframe に代わることはありません。使用する必要はありません。フェンス付きフレームは、異なるトップレベル パーティションのデータが同じページに表示される必要がある場合に、よりプライベートなフレームとして使用することをおすすめします。
ポータルに埋め込む
ポータル（<portal>）は、独立したブラウジング コンテキストを持つ HTML 要素として提案されています。これにより、ページ遷移の操作性が向上します。ポータルは iframe などのコンテンツを埋め込みますが、ユーザーはポータルのコードにアクセスできません。ポータルは表示専用で、ユーザーが操作することはできません。
ポータルは、単一ページ アプリケーションのシームレスな遷移と、複数ページ アプリケーションの複雑さの低減を実現します。こうした遷移をアニメーション化し、ブラウザ ウィンドウのコンテンツをすばやく置き換えることができます。
<portal src="https://example.com/"></portal>
ポータルの仕様はまだ開発の初期段階です。
埋め込みに使用されるその他の HTML 要素
ウェブの歴史の中で、コンテンツを埋め込むための多くの HTML 要素が提案され、API が作成されてきました。しばらくは、複数の <frame> 要素と <frameset> 要素を持つサイトを作成することが一般的でした。複数の <frameset> 要素があるサイトでは、個々のフレームのソースに関係なく、アドレスバーに親ページの URL が表示されていました。これにより、サイト内のコンテンツへのリンクを共有することが困難になっていました。これらの API は非推奨になりました。
以前は、Java <applet> 要素などのプラグイン テクノロジーが他のユースケースに対応するために使用されていました。これは後に <object> 要素に置き換えられました。これらの要素はどちらも、Flash プラグインの表示によく使用されていましたが、他の HTML 要素（iframe に似たもの）の表示にも使用されていました。<canvas>、<audio>、<video>、<svg> などの他の要素により、<object> 要素と <applet> 要素の両方が廃止されました。
<object> と <embed> はまだ正式に非推奨になっていませんが、異常な動作があるため、使用しないことをおすすめします。<applet> は 2017 年に HTML 仕様から削除されました。
まとめ
既存の iframe 仕様を使用して、任意のウェブサイトにコンテンツを安全に埋め込むことができます。<fencedframe> や <portal> など、セキュリティとスタイルの改善のために、さらに多くの HTML 要素が提案されています。フェンス付きフレームの提案の進捗状況については、今後も随時お知らせします。