境界線の解体：CSP sandbox ディレクティブが握る「ブラウザの檻」の真価
セキュリティ・アーキテクトとして、我々は日々「信頼の境界」を設計している。しかし、Webというプロトコルは、設計当初から「ドキュメント間でのリソース共有」を前提としていた。この設計思想が、今日のXSSやクリックジャッキングといった脆弱性の温床となっているのは周知の事実だ。
特に、レガシーな広告フレームや、サードパーティの埋め込みコンテンツ（iframe）は、攻撃者にとっての「安全な隠れ家」になり得る。ここで、単なる防御策ではなく、ブラウザの実行コンテキストを強制的に制限する Content-Security-Policy: sandbox の深層に切り込んでみたい。
1. ブラウザの「隔離」を理解する：サンドボックスの物理層
CSPの sandbox ディレクティブは、単なるWeb標準の機能ではない。これはブラウザのレンダリングエンジン（BlinkやWebKit）に対し、特定のiframe内での「実行権限を剥奪する」という、極めて低レイヤに近い強制力を発揮する命令だ。
通常、iframeは親ドキュメントと（同一生成元ポリシーが許す限り）密接に連携する。だが、sandboxを適用した瞬間、そのiframeは「一意のオリジン（Unique Origin）」として隔離される。これは、ローカルストレージの共有、Cookieのアクセス、さらにはスクリプトの実行フローまでもが、隔離された空間内で「無効化」または「厳格化」されることを意味する。
2. なぜ allow-scripts が「毒」になり得るのか
多くのエンジニアは、動かしたい機能に合わせて allow-scripts や allow-forms を安易に追加しがちだ。しかし、ここが最大の盲点となる。
例えば、攻撃者がプロンプトインジェクションを用いて埋め込みコンテンツを汚染し、それが親ページへのデータ窃取（PostMessageインターフェースの悪用）を試みるケースがある。sandbox で allow-same-origin を付与していれば、その隔離は形骸化し、攻撃者は親ドキュメントのセッション情報を奪取できる可能性すらある。
推奨される厳格なCSP設定例
外部からのiframe埋め込みに対しては、極力権限を絞り込む
Content-Security-Policy: sandbox allow-scripts allow-popups;
- 注意点:
allow-same-originを付与する場合、それは「サンドボックスを無効化する」ことと同義であることを肝に銘じろ。もしどうしてもJSが必要な場合でも、allow-same-originは外すのが鉄則だ。これにより、iframe内のスクリプトは独自のオリジンとして扱われ、親のCookieやlocalStorageに直接触れることができなくなる。
3. 生成AI時代の新たな脅威：プロンプトの「コンテナ化」
現在、我々が対峙している最大の脅威は、生成AIの出力がそのままWeb UIへ描画されることによる「AI誘発型XSS」だ。攻撃者はAIに巧妙なプロンプトを送り込み、サンドボックスを突破するためのHTMLタグを生成させようとする。
ここで防衛層としてのアーキテクチャ設計が必要になる。AIが生成したコンテンツをiframeで囲う際、以下の「要塞化」設定を強制すべきだ。