iframe の sandbox 属性.

HTML Living Standard で定義される <iframe> の sandbox 属性は、埋め込みコンテンツに最小権限ポリシーを適用します。空の値(sandbox="")を指定すると、スクリプト、プラグイン、フォーム送信、トップレベルおよび同一オリジンの遷移、ポップアップ、ポインターロック、自動再生、さらに Pointer Lock API と Presentation API を無効化し、フレームを一意の不透明オリジンに強制します。そのため、親ページの Cookie、localStorage、DOM を読み取ることはできません。機能はトークンごとに 1 つずつ再付与します。すなわち allow-scripts、allow-same-origin、allow-forms、allow-popups、allow-modals、allow-downloads、allow-top-navigation-by-user-activation です。

決定的な落とし穴は、allow-scripts allow-same-origin を組み合わせることです。これはフレームを本来のオリジンに戻し、かつ JavaScript の実行を許可するため、サンドボックス化されたコードは自身の DOM に手を伸ばし、入れ子のフレームから sandbox 属性を削除するだけで保護を無効化できてしまいます。真に信頼できないコンテンツをホストするには、別のオリジンに隔離し、サンドボックスを Content-Security-Policy: sandbox(マークアップからは除去できません)や Cross-Origin-Opener/Embedder ポリシーと組み合わせてください。サンドボックス化は、広告、リッチテキストプレビュー、サードパーティウィジェットの安全なレンダリングを支えています。Google の Caja や、CodePen・JSFiddle といった現代のサービスは、使い捨てのオリジン上でサンドボックス化されたフレームを用い、ホストページを危険に晒すことなく攻撃者が制御するコードを実行しています。

flowchart TD
  A[親ページ] --> B["&lt;iframe sandbox&gt;<br/>信頼できないコンテンツを埋め込み"]
  B --> C{どのトークンを指定?}
  C -->|"sandbox=&quot;&quot; (空)"| D[不透明オリジン、スクリプト無効、<br/>フォーム無効、遷移無効]
  C -->|allow-scripts のみ| E[スクリプトは実行、依然として<br/>不透明オリジン - 安全]
  C -->|"allow-scripts +<br/>allow-same-origin"| F[本来のオリジン + スクリプト:<br/>フレームが自身の sandbox を<br/>除去可能 = 脱出]
  E --> G[CSP: sandbox ヘッダーを追加<br/>別オリジン = 多層防御]