本文
結論から言うと、MCP Appsを安全にする中心は「iframeを使っているから安全」と考えないことです。MCP Appsは、MCP serverが返す対話UIをhostがsandboxed iframeで表示し、UIとhostの通信をJSON-RPCで扱う仕組みです。[1] iframe sandboxはparent pageのDOM、cookie、local storageへ直接触れないようにしますが、UIが要求したtool callをhostが実行できれば、書込みやデータ取得という副作用は起こり得ます。実装時には、表示の隔離、外部通信の制限、messageの送信元検証、tool権限と承認を別々に確認します。
最初に、Appの権限を「画面に表示する権限」と「外部へ作用する権限」に分けます。MCP Appsのtool UI templateは事前宣言でき、hostはrender前に取得・cache・security reviewできます。[2] ここでは、どのtoolがUIを出すか、画面がread-onlyか、保存・送信・削除を要求し得るかを、tool schemaとは別に棚卸しします。UIがきれいに見えることは、操作先が正しいことの証明ではありません。特に請求、CRM更新、権限変更、公開、削除は、UI上のbutton labelではなくserver側のtool policyで拒否または承認待ちにします。
次に、CSPをApp固有のallowlistとして扱います。MCP AppsのHTMLは通常のsame-origin web appではなくsandboxed iframeで動くため、network requestを行うAppは_meta.ui.cspにoriginを宣言します。connectDomainsはfetch、XHR、WebSocket向け、resourceDomainsはscript、style、image、font向けです。[3] 開発時のlocalhostも含め、実際に必要なoriginだけを明示します。https:のような広い指定や、便宜上のwildcardは避けます。さらにCSPは「browserに何を許すか」、CORSは「API serverがどのoriginを受け入れるか」を決める別の層です。片方だけを通しても、意図した通信になるとは限りません。
ただし、CSPはprompt injection、XSS、認可不備を解決する代替手段ではありません。W3CはCSPをcontent injectionの被害を抑えるdefense-in-depthと位置付け、入力検証・output encodingの代わりではないと明記しています。[4] Appが外部文書、検索結果、MCP tool outputを表示するなら、その内容を「操作命令」ではなく非信頼データとして扱います。CSPに通したCDNやAPIが侵害された場合、allowlistだけでは安全性を保証できません。
iframeとhostのpostMessageも、文字列を受け取るだけの実装にしません。MCP AppsのPostMessageTransportは、event.sourceを照合するためのwindowを必須にし、view側はwindow.parent、host側は対象iframeのcontentWindowを渡す設計です。[5] hostはmessageのschema、request ID、許可したmethod、対象toolを検証し、想定外のmessageをfail-closeで拒否します。Appが「この操作は安全」と説明しても、approval判断をAppの表示文言やmodel outputへ委ねません。
書込み操作は、read、reversible write、不可逆・高影響の三段階に分けます。readは必要最小限のscopeで自動実行を検討できます。下書き保存など戻せるwriteは、対象・差分・実行主体をpreviewし、監査可能にします。送信、公開、権限変更、削除、支出はhost側で人の確認を要求し、承認の対象をtool名だけでなくarguments、対象record、effectまで固定します。ChatGPTのdeveloper mode向け公式案内も、write/modify actionについてcontextと影響に応じたconfirmation、危険操作のblock、adminによる事前test・vetを示しています。[6]
海外では、MCP Appsは2026年1月にofficial extensionとして公開され、ChatGPT、Claude、Goose、Visual Studio Codeのsupportが案内されました。[7] 一方で、hostごとにsupportするcapability、承認UI、CSPのhost-specific originの扱いは同じではありません。対応clientを推測せず、対象hostでread tool、write tool、拒否、CSP違反、message偽装、network errorを実測します。MCP server自体が信頼できない場合のprompt injection riskも、OpenAIは明示しています。[6]
MCP Appのセキュリティレビューを相談する。
一次情報と確認範囲
確認日：2026年9月17日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。
- MCP Appsはhost管理のsandboxed iframeで表示される
- templateは事前宣言でき、hostはrender前にreviewできる
- CSPの`connectDomains`と`resourceDomains`は通信・resource originを分ける
- CSPはcontent injectionへのdefense-in-depthで、入力検証の代替ではない
- PostMessageTransportは`event.source`を照合する
- ChatGPTではwrite/modify actionに確認・block・admin reviewを設け得る
- MCP Appsは2026年1月にofficial extensionとして公開された