GitHub documentation update: fix: add sandbox and CSP to playground preview iframe は、GitHub全体の仕様変更ではなく、GitHub上の microsoftgraph/microsoft-graph-toolkit リポジトリで公開された Microsoft Graph Toolkit のプレイグラウンド向けセキュリティ修正です。結論から言うと、ユーザーが入力したスクリプトをプレビュー用 iframe 内で実行する際、信頼できない外部通信を抑止するために sandbox 属性と CSP（Content Security Policy）メタタグが追加されました。管理者や開発者は、プレイグラウンド、Storybook、社内ドキュメントサイトなどで「ユーザー入力コードを iframe でプレビューする仕組み」を使っていないか確認し、外部API呼び出し・認証ポップアップ・画像読み込みが想定どおり動くかをテストする必要があります。(GitHub)
GitHubの「GitHub documentation update: fix: add sandbox and CSP to playground preview iframe」は何が変わるのか
今回の変更は、Microsoft Graph Toolkit のプレイグラウンドプレビュー用 iframe に対するセキュリティ強化です。対象のPR #3489は「playground preview iframe に sandbox 属性と Content-Security-Policy メタタグを追加し、ユーザー supplied scripts からの信頼できない outbound network calls をブロックする」と説明されています。GitHub上では、1ファイルの変更として .storybook/addons/codeEditorAddon/codeAddon.js に20行が追加されています。(GitHub)
重要なのは、この変更が GitHub.com のリポジトリ設定や GitHub Actions の動作を変えるものではない という点です。影響するのは、Microsoft Graph Toolkit のプレイグラウンドや、それをフォーク・流用しているドキュメントサイト、Storybook環境、コード実行プレビュー機能です。
変更の狙いは「ユーザー入力スクリプトの外部通信を絞る」こと
プレイグラウンド型のUIでは、ユーザーが入力したHTMLやJavaScriptをその場で実行し、結果を iframe で表示する構成がよく使われます。便利な一方で、許可範囲を広くしすぎると、入力されたスクリプトが意図しない外部サイトへ通信したり、データを送信したりするリスクがあります。
今回のPRは、そのリスクを抑えるために次の2つを組み合わせています。
| 追加された対策 | 役割 | 実務上の意味 |
|---|---|---|
iframe の sandbox 属性 | iframe内のスクリプト、フォーム、ポップアップなどの動作を制限する | プレビュー領域を通常のページより制約された環境で動かす |
| CSPメタタグ | 読み込み・通信できるリソースの出所を制限する | fetch や XMLHttpRequest などの外部通信先を許可リスト化する |
CSPは、ページ内のコードが読み込めるリソースや実行できるスクリプトの範囲をブラウザーに指示する仕組みです。MDNでは、CSPはXSSなどのセキュリティ脅威のリスクを防止または最小化する機能であり、読み込みを許可するリソース、特にJavaScriptリソースの制御に使われると説明されています。(MDNウェブドキュメント)
具体的に追加された設定
PR #3489では、プレビュー用 iframe に次のような sandbox 設定が追加されています。(GitHub)
sandbox="allow-scripts allow-same-origin allow-popups allow-popups-to-escape-sandbox allow-forms"また、iframe内に生成されるHTMLの <head> に CSP メタタグが追加され、default-src、script-src、style-src、connect-src、img-src、font-src、frame-src、form-action、object-src、base-uri が指定されています。特に connect-src では、Microsoft Graph や Microsoft Entra ID のログイン関連ドメインなど、許可された通信先が明示されています。(GitHub)
connect-src が特に重要な理由
今回の要点は、単に iframe を隔離するだけではなく、ユーザー入力スクリプトからの外部ネットワーク通信を制限することです。その中心になるのが CSP の connect-src です。
MDNによると、connect-src は fetch()、XMLHttpRequest、WebSocket、EventSource、navigator.sendBeacon() など、スクリプトから行われる通信先URLを制限するディレクティブです。つまり、ユーザーがプレイグラウンドに書いたスクリプトが任意の外部URLへデータを送ることを防ぎやすくなります。(MDNウェブドキュメント)
実務では、次のようなコードが影響を受ける可能性があります。
fetch("https://example.com/collect", {
method: "POST",
body: JSON.stringify(data)
});このような通信先が CSP の connect-src に含まれていなければ、ブラウザー側で通信が拒否されます。これは不具合ではなく、今回の変更の目的に沿った動作です。
影響を受ける対象者
今回の変更で確認が必要なのは、主に次の利用者です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Graph Toolkit のプレイグラウンド利用者 | サンプルコードの実行時に、外部APIや画像、認証画面がブロックされないか |
| リポジトリをフォークしている開発者 | .storybook/addons/codeEditorAddon/codeAddon.js の変更を取り込む必要があるか |
| 社内ドキュメントサイト管理者 | ユーザー入力コードを iframe で実行する独自プレビュー機能が同様のリスクを持たないか |
| セキュリティ担当者 | 任意コード実行型のデモ環境で、外部通信先が許可リスト化されているか |
| Microsoft Graph Toolkit を本番アプリで使う開発者 | 本番コンポーネントではなく、プレイグラウンド・Storybook周辺の変更かを切り分ける |
Microsoft Graph Toolkit自体は、Microsoft Graphにアクセスするための再利用可能なコンポーネントと認証プロバイダーのコレクションです。Microsoft Learnでは、Webアプリケーション、Teamsタブ、PWA、Electronアプリ、SharePoint Webパーツなどで利用できると説明されています。(Microsoft Learn)
ただし、今回の変更は Microsoft Graph Toolkit のすべての本番利用コードへ一律に影響するものではありません。変更ファイルは Storybook の code editor addon 配下にあるため、まずは自社環境で該当ファイルや同等のプレビュー実装を使っているかを確認するのが現実的です。(GitHub)
管理者・開発者が確認すべきポイント
フォークや独自デプロイに変更が入っているか確認する
Microsoft Graph Toolkit のリポジトリをフォークして社内用ドキュメントやサンプル環境を運用している場合、PR #3489の内容が取り込まれているかを確認してください。PRは fix/msrc-117698-block-untrusted-calls ブランチから main にマージされ、関連Issue #3488「MSRC 117698 – block untrusted calls」を閉じるものとして扱われています。(GitHub)
確認する場所は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
.storybook/addons/codeEditorAddon/codeAddon.js | storyElement.setAttribute('sandbox', ...) が追加されているか |
iframe内HTMLの <head> | Content-Security-Policy の meta http-equiv が追加されているか |
connect-src | 必要な Microsoft Graph / 認証関連ドメインが許可されているか |
| 自社独自の外部API | 必要な通信先がブロックされていないか、またはブロックされるべき通信か |
プレイグラウンドのサンプルを再テストする
この変更はセキュリティ修正ですが、既存のサンプルコードに副作用が出る可能性があります。特に、プレイグラウンドで外部API、外部画像、外部フォント、外部iframeを読み込んでいる場合は、CSPにより拒否されることがあります。
ブラウザーの開発者ツールで次を確認してください。
| テスト観点 | 確認方法 | よくある症状 |
|---|---|---|
| Graph API通信 | Networkタブで graph.microsoft.com などへの通信を確認 | データが表示されない |
| 認証ポップアップ | ログインボタンや認証フローを実行 | ポップアップが開かない、ログイン後に戻れない |
| 外部API呼び出し | 任意の fetch() を含むサンプルを実行 | ConsoleにCSP違反が表示される |
| 画像読み込み | 外部画像URLを使ったサンプルを表示 | 画像が空白になる |
| iframe内フォーム | フォーム送信を含むサンプルを実行 | 送信できない、または拒否される |
PR内のレビューチェックリストでも、ローカル実行、既存Storybookの回帰確認、Edgeと非Chromium系ブラウザーを含む2ブラウザーでのテストが求められています。運用側でも同じ観点で検証すると、ブラウザー差分による見落としを減らせます。(GitHub)
CSP違反を「単なるエラー」として扱わない
CSP導入後にConsoleへ次のようなメッセージが出る場合があります。
Refused to connect to ... because it violates the Content Security Policy directive "connect-src ..."この表示は、許可されていない通信がブロックされたことを示します。すぐに許可リストへ追加するのではなく、まず次の順に判断してください。
| 判断ステップ | 確認内容 |
|---|---|
| その通信は必要か | サンプル表示に本当に必要な通信か、古いデバッグ用コードか |
| 送信される情報は何か | トークン、ユーザー情報、テナント情報、入力内容が含まれないか |
| 代替できるか | バックエンド経由、モックデータ、Microsoft Graphの正規エンドポイントで代替できないか |
| 許可範囲は最小か | ワイルドカードではなく、必要なホストだけに限定できるか |
セキュリティ修正の目的は「動かないサンプルをすべて動かす」ことではなく、「不要または危険な外部通信を止める」ことです。特にプレイグラウンドは、読者や開発者が自由にコードを試せる場であるほど、通信先の制限が重要になります。
自社のiframeプレビューにも応用する際の注意点
今回の修正は、社内ポータル、技術ブログ、APIドキュメント、デザインシステムのStorybookなどにも参考になります。ただし、設定をそのままコピーするのは避けるべきです。
allow-scripts と allow-same-origin の併用は慎重に扱う
PRでは、ES module loading のために allow-same-origin が必要であり、データ流出は下のCSPメタタグでブロックするというコメントが追加されています。(GitHub)
一方、MDNは、埋め込まれる文書が親ページと同一オリジンの場合、allow-scripts と allow-same-origin を同時に使うと、埋め込まれた文書が sandbox 属性を削除できるため、sandboxを使わない場合と比べて安全性が下がる可能性があると注意しています。(MDNウェブドキュメント)
そのため、自社実装では次の方針を検討してください。
| 方針 | 内容 |
|---|---|
| 可能なら別オリジンで配信する | preview.example.com のように、プレビュー用ドメインを分離する |
| 必要な権限だけ付ける | allow-popups や allow-forms を本当に必要な場面だけに限定する |
| CSPを最小権限にする | connect-src * のような広すぎる指定を避ける |
| 入力のサニタイズを続ける | CSPを入れても、入力検証やサニタイズを省略しない |
| 監視を入れる | CSP違反をログ化し、意図しない通信試行を把握する |
CSPメタタグとHTTPヘッダーの違いも理解する
今回のPRでは、生成されるiframe内HTMLに CSP メタタグを挿入しています。これは、プレビューHTMLを動的に組み立てるようなケースでは実装しやすい方法です。
ただし、MDNはCSPを Content-Security-Policy レスポンスヘッダーで配信できると説明しており、meta http-equiv による指定も可能だが、CSPのすべての機能に対応するわけではないとしています。自社サービスでサーバー側の制御ができるなら、HTTPヘッダーでのCSP配信を基本にし、iframe内で生成するHTMLには必要に応じてメタタグを併用する設計が安全です。(MDNウェブドキュメント)
移行・展開時に失敗しやすいポイント
外部APIを使うサンプルが突然動かなくなる
最も起きやすいのは、これまで自由に fetch() できていた外部APIがCSPで止まるケースです。たとえば、天気API、社内検証API、画像生成API、ログ収集エンドポイントなどをプレイグラウンドのサンプルから直接呼んでいる場合、許可されていない通信として拒否されます。
対応は3つに分けて考えると整理しやすくなります。
| 状況 | 推奨対応 |
|---|---|
| Microsoft Graph の正規サンプル | 許可済みドメインで動くか確認し、認証フローをテストする |
| 教材用の外部API | モックデータに置き換える、またはバックエンドプロキシ経由にする |
| 不要な外部通信 | 許可せず削除する |
| 業務上必須の通信 | 送信データを確認した上で、最小範囲でCSPに追加する |
認証ポップアップやフォームの検証を後回しにする
今回の sandbox には allow-popups、allow-popups-to-escape-sandbox、allow-forms が含まれています。これは、認証フローやフォームを完全に止めないための調整と考えられます。(GitHub)
ただし、ポップアップやフォームはブラウザー、認証方式、テナント設定によって挙動が変わることがあります。特に Microsoft Entra ID 認証を含むサンプルでは、ログイン開始、同意画面、リダイレクト後の復帰、トークン取得後のGraph API呼び出しまでを一連で確認してください。
Microsoft Graph Toolkitの将来計画を見落とす
Microsoft Learnでは、Microsoft Graph Toolkit は2025年9月1日から非推奨となり、2026年8月28日に完全な退職が予定されていると案内されています。開発者には、Microsoft Graph SDKやその他のサポートされているMicrosoft Graphツールへの移行が推奨されています。(Microsoft Learn)
そのため、今回の修正を取り込むだけで終わらせず、次のように整理しておくと無駄な再作業を減らせます。
| 利用状況 | 次の判断 |
|---|---|
| 社内ドキュメントでプレイグラウンドだけ使っている | セキュリティ修正を取り込みつつ、廃止時期までの運用期限を決める |
| 本番アプリでMGTコンポーネントを使っている | Microsoft Graph SDKなどへの移行計画を作る |
| Storybookだけフォークしている | 今回のiframe/CSP修正を自社Storybookにも反映できるか確認する |
| 新規開発を検討している | MGT前提ではなく、サポート継続される選択肢を優先する |
実務での確認手順
管理者や開発者は、次の順番で確認すると効率的です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | 自社で Microsoft Graph Toolkit のフォーク、Storybook、プレイグラウンドを使っているか確認 | 対象環境の有無が分かっている |
| 2 | .storybook/addons/codeEditorAddon/codeAddon.js の差分を確認 | sandbox と CSPメタタグの有無が分かっている |
| 3 | 代表的なサンプルをEdgeと非Chromium系ブラウザーで実行 | 認証、Graph API通信、画面表示の結果を確認済み |
| 4 | ConsoleとNetworkでCSP違反を確認 | ブロックされた通信先を一覧化している |
| 5 | 許可・削除・代替の判断を行う | 不要な外部通信を許可リストに追加していない |
| 6 | 本番または社内公開環境へ展開 | 回帰テストとロールバック手順が用意されている |
| 7 | MGTの移行計画を更新 | 非推奨・退職予定を踏まえた期限が決まっている |
まとめ：今回のGitHub documentation updateで今すぐ確認すべきこと
今回の「GitHub documentation update: fix: add sandbox and CSP to playground preview iframe」は、GitHubの一般ユーザー設定ではなく、Microsoft Graph Toolkit のプレイグラウンドプレビューを安全にするための修正です。ポイントは、iframeの sandbox と CSPメタタグにより、ユーザー入力スクリプトの権限と外部通信先を絞ることです。
今すぐ行うべきことは3つです。まず、自社で対象リポジトリのフォークや同等のiframeプレビュー機能を使っているか確認します。次に、connect-src によって必要なGraph API通信や認証フローがブロックされていないか検証します。最後に、外部APIを無条件に許可するのではなく、不要な通信を削除し、必要な通信だけを最小限の許可リストに残します。
プレイグラウンドやドキュメントサイトは「本番アプリではない」と見なされがちですが、ユーザー入力コードを実行する以上、外部通信の制御は本番と同じくらい重要です。今回の修正をきっかけに、社内のStorybook、コードサンドボックス、APIドキュメントのプレビューiframeもあわせて点検しておくと、安全性と運用安定性の両方を高められます。
コメント