公開日: 2026 年 4 月 16 日
ウェブ アプリケーションは複雑化しており、特に生成 AI の統合が進んでいるため、ユーザーデータの保護が最優先事項となっています。そこで、ドキュメントとワーカーのネットワーク サンドボックスを作成する新しいセキュリティ メカニズムである接続許可リストのオリジン トライアルを発表します。
背景
最新のウェブ エコシステムでは、センシティブ データがクライアントとサーバーの間を常に移動しています。このモビリティと、サードパーティ スクリプトの複雑なサプライ チェーン、生成 AI から動的に生成されるコードの増加が組み合わさることで、データの引き出しのリスクが大幅に高まります。
悪意のあるスクリプト、バンドルされたライブラリの脆弱性、生成 AI によって生成されたコードの意図しない動作により、アプリケーション レベルのチェックをバイパスして、機密情報を不正なエンドポイントに送信される可能性があります。コンテンツ セキュリティ ポリシー（CSP）は、ページが読み込んで実行できるものを制御する強力なツールですが、その複雑さを管理して、ページが通信する場所を具体的に制限することは難しい場合があります。多くの場合、広範なポリシーになり、不正なネットワーク アクティビティの余地が残ります。
接続許可リストのサンドボックス
接続許可リストは、ページから発信されるすべてのネットワーク接続のゲートキーパーをブラウザにすることで、これらのリスクに直接対処する方法を提供します。Connection-Allowlist HTTP レスポンス ヘッダーを含めることで、サイトは、ドキュメントやウェブワーカーなど、コンテキストによって開始されるすべてのネットワーク通信で許可される正確な URL パターンを指定します。
この機能は、フレームワーク レベルの「デフォルトで拒否」ファイアウォールを適用します。サブリソースの取得、ナビゲーション リダイレクト、WebSocket 接続など、接続が確立される前に、ブラウザは許可リストに対して宛先を確認します。エンドポイントが一致しない場合、ブラウザはネットワーク レベルで接続をブロックします。悪意のあるコードがアプリケーション レベルのロジックをバイパスしようとしても、ブラウザはネットワーク境界を維持します。
接続許可リストの仕組み
接続許可リストは、ページから発信されるすべてのネットワーク接続のゲートキーパーをブラウザにすることで、これらのリスクに直接対処する方法を提供します。Connection-Allowlist HTTP レスポンス ヘッダーを含めることで、サイトは、コンテキストによって開始されるすべてのネットワーク通信で許可される正確な URL パターンを指定します。オリジン トライアルでは、ドキュメント コンテキストでのみサポートされています。
サブリソースの取得、ナビゲーション リダイレクト、WebSocket 接続など、接続が確立される前に、ブラウザは許可リストに対して宛先を確認します。エンドポイントが一致しない場合、ブラウザはネットワーク レベルで接続をブロックします。これにより、悪意のあるコードがアプリケーション レベルのロジックをバイパスしようとしても、ネットワーク境界が維持されます。
response-origin トークンを使用する
response-origin トークンを使用すると、レスポンスが配信されるオリジンを許可リストに動的に追加できます。
Connection-Allowlist: ("https://api.example.com/*" response-origin)
この例では、ページはそのオリジンと指定された API エンドポイントの任意のパスに接続できます。
違反を報告する
サイトの機能を中断することなく潜在的な問題をモニタリングするには、Connection-Allowlist-Report-Only ヘッダーを使用します。このバリアントは、
ポリシーを解析し、Reporting
APIを使用して指定されたエンドポイントに違反レポートを送信します。
Connection-Allowlist: ("https://trusted.com/*"); report-to=security-endpoint
主なユースケース
接続許可リストは、セキュリティの高い環境や動的な環境で役立ちます。
- 生成 AI と信頼できないコード: サイトで生成されたコードや信頼できないコードをユーザーが実行できる場合（シート キャンバスや開発サンドボックスなど）、接続許可リストを使用すると、コードが外部ドメインにデータを漏洩するのを防ぐことができます。
- サードパーティの監視: サードパーティ スクリプトが侵害された場合でも、不正なサーバーにデータを送信できないようにすることができます。
- アーキテクチャ上の保護: アプリケーションの機密性の高い部分に厳格なネットワーク境界を適用し、承認されたバックエンドとのみ通信できるようにします。
コンテンツ セキュリティ ポリシーとの違い
接続許可リストと CSP の目標は似ていますが、補完的な関係にあります。
- ネットワーク レベルの焦点: 接続許可リストは、リソースの読み込み方法や実行方法ではなく、ネットワーク接続の宛先に重点を置いています。
- 包括的なカバレッジ: ナビゲーション、リダイレクト、さまざまなウェブ プラットフォーム API（Fetch、WebRTC、WebTransport、DNS プリフェッチ、プリロードなど）を統合的にカバーします。
- 構文の簡素化: 接続許可リストは単一のタスクに焦点を当てているため、構成とセキュリティ監査が簡素化されます。
接続許可リストを試す
接続許可リスト機能は、ローカル テストで利用できます。オリジン トライアルは、Chrome 148 から Chrome 151 まで実施される予定です。オリジン トライアルの進行に伴い、機能が追加されます。このトライアルの開始時点では、レポート機能はドキュメント コンテキストに限定されており、専用ワーカー、共有ワーカー、サービス ワーカーは対象外です。サポートされている内容の詳細については、オリジン トライアルに登録する をご覧ください。
ローカルでテストする
- フラグを有効にする: Chrome を開き、
chrome://flags/#connection-allowlistに移動します。フラグを [有効] に設定します。 - ヘッダーをデプロイする:
Connection-AllowlistHTTP レスポンス ヘッダーを送信するようにローカル開発サーバーを構成します。例:Connection-Allowlist: ("https://api.example.com/*" response-origin)。 - DevTools で確認する: Chrome DevTools を開き、ネットワーク リクエストをトリガーする操作を行います。
- [ネットワーク] パネル: 「blocked:other」または接続エラーが表示されるリクエストを確認します。
- [問題] タブ: ヘッダーに解析エラーがある場合は、詳細なレポートを確認します。
オリジン トライアルに登録する
ローカル テストは開発に最適ですが、本番環境でユーザーの接続許可リストを有効にするには、オリジン トライアルに登録する必要があります。
- Chrome オリジン トライアル ダッシュボード に移動します。
- [接続許可リスト] オリジン トライアルを見つけて、[登録] をクリックします。
- オリジン トライアルを始める ガイドの説明に沿って、生成されたトークンをサイトのページまたはヘッダーに追加します。
オリジン トライアルは、Chrome 148 から Chrome 151 まで実施される予定です。 オリジン トライアルの進行に伴い、機能が追加されます。接続許可リストをテストする際は、既存のウェブ セキュリティ メカニズムを引き続き使用することを強くおすすめします。Intent to Experiment では、接続許可リストの実装でカバーされるネットワーク エンドポイントについて詳しく説明しています。
フィードバックを送信
機能の設計とユーティリティに関するフィードバックをお寄せください。問題が発生した場合や、改善のための提案がある場合は、チームまでご連絡ください。
- GitHub:
WICG/connection-allowlistsリポジトリで問題をオープンするか、既存の問題にコメントしてください。 - Chromium バグトラッカー: Chromium バグトラッカーで問題を作成してください。