iframeサンドボックスと権限分離の境界

iframe は別ドキュメントを現在のページに埋め込む仕組みですが、埋め込む相手が広告・ウィジェット・ユーザー投稿の HTML など信頼できないコードであることは珍しくありません。sandbox 属性は、その埋め込みフレームから危険な能力を奪い、限定的な実行環境に閉じ込めるための機能です。ここでは各トークンが何を無効化するのか、なぜ allow-same-origin が境界を壊すのか、そして Permissions Policy や CSP との役割分担を原理から見ていきます。

sandbox は「全部禁止」から始まる減算モデル

最大のポイントは、sandbox 属性を付けた時点でフレームの能力がほぼすべて無効化されることです。何も値を書かない <iframe sandbox src="..."> は最も制限が強く、そこから sandbox="allow-scripts allow-forms" のように allow- トークンを並べて、必要な能力を1つずつ戻していきます。CSP のような「許可リストを足していく」発想に似た、加算ではなく減算のモデルです。

<!-- 最も厳しい: スクリプトもフォームも遷移もすべて不可 -->
<iframe sandbox src="https://untrusted.example/widget"></iframe>

<!-- スクリプトとフォーム送信だけ戻す -->
<iframe sandbox="allow-scripts allow-forms"
        src="https://untrusted.example/widget"></iframe>

空の sandbox を付けたフレームは、内部的に**不透明オリジン（opaque origin）**を割り当てられます。これは「どのオリジンとも一致しない、生成のたびに異なる一意のオリジン」で、自分自身とも同一オリジンになりません。結果として、そのフレーム内のスクリプトは自身の localStorage／sessionStorage、document.cookie、IndexedDB などオリジン紐付けのストレージに一切アクセスできなくなります。オリジンが何を意味するかは 同一オリジンポリシーとサイト分離の信頼境界 の通りで、sandbox はその境界を「最も孤立した側」に倒す操作だと捉えると理解しやすいです。

各トークンが無効化／復帰させる能力

主要なトークンと、それが制御する能力を整理します。

特に注意したいのが トップレベル遷移 です。allow-top-navigation を与えないと、サンドボックス内のスクリプトは top.location = '...' や target="_top" のリンクで親ページごと別サイトへ飛ばすことができません。広告フレームがユーザーを勝手にフィッシングサイトへリダイレクトする典型的な攻撃は、これで遮断されます。より安全な中間として allow-top-navigation-by-user-activation があり、これは実際のクリックなどユーザー操作を伴うときだけトップ遷移を許します。自動リダイレクトは止めつつ、正規のリンククリックは通したい広告枠などで使われます。

allow-same-origin が境界を壊す理由

allow-same-origin は他のトークンと性格が違います。これは能力を1つ足すというより、フレームを不透明オリジンから本来のオリジンへ戻すスイッチです。これを付けると、フレームは本来のオリジンとして扱われ、同一オリジンであれば Cookie・ストレージ・postMessage を超えた DOM 直アクセスまで可能になります。

危険なのは allow-same-origin と allow-scripts を同時に許す場合です。両方が揃うと、フレーム内のスクリプトは自分が埋め込まれている <iframe> 要素の DOM へ（同一オリジンなら）アクセスでき、自分自身の sandbox 属性を書き換えてから再読み込みを誘発できます。属性の評価は次回ロード時に効くため、sandbox を緩めた状態で読み直すことで、自力でサンドボックスを脱出できてしまいます。さらに同一オリジンを名乗れる以上、親ページのストレージや Cookie とオリジンを共有し、サンドボックスの「隔離」という前提自体が崩れます。

sandbox・Permissions Policy・CSP の役割分担

iframe の隔離は1つの属性では完結せず、性質の異なる3つの仕組みを重ねて設計します。

sandbox が「フレーム内でできる操作」を能力レベルで削るのに対し、<iframe> の allow 属性が指定する Permissions Policy は、カメラ・マイク・位置情報・全画面・支払いといった強力機能の利用許可をフレームへ委譲するかどうかを制御します。両者は補完関係です。たとえばカメラを使うウィジェットなら sandbox="allow-scripts" で能力を絞りつつ、allow="camera" で必要な機能だけを明示的に渡します。allow で渡さない限り、たとえ allow-scripts でスクリプトが動いても getUserMedia() は権限拒否になります。

<iframe
  sandbox="allow-scripts allow-forms"
  allow="camera; microphone 'none'; geolocation 'none'"
  src="https://untrusted.example/recorder">
</iframe>

CSP 側は埋め込み関係そのものを制御します。親が frame-src で「自分が読み込んでよい iframe の URL」を制限し（Content Security Policy の内部動作と回避耐性 で扱う default-src フォールバックも効きます）、逆に埋め込まれる側は frame-ancestors で「自分を iframe に入れてよい親」を制限してクリックジャッキングを防ぎます。frame-ancestors 'none' は旧来の X-Frame-Options: DENY の後継で、CSP として一元管理できる点が利点です。

設計の指針 — 最小権限で組み立てる

実務での組み立て方は明快です。まず値なしの sandbox から始め、そのコンテンツが本当に必要とする能力だけを allow- で戻します。スクリプトが要るなら allow-scripts、フォームが要るなら allow-forms、というように加算は最小限にとどめます。allow-same-origin は、信頼できないコンテンツに対しては原則付けない。どうしてもストレージ等が要るなら、必ず専用の分離オリジンに隔離したうえで付けます。

そのうえで Permissions Policy の allow で強力機能を絞り、CSP の frame-src／frame-ancestors で埋め込みの両方向を固めます。信頼できない HTML を直接描画する場面では、サンドボックス化フレームへの注入経路そのものも DOM-based XSS の sink/source 分類と緩和原理 の観点で塞いでおくべきです。sandbox 単体に頼らず、能力の無効化・機能委譲・埋め込み制御の3層を重ねることが、第三者コンテンツを安全に同居させる唯一の堅い設計です。