ChromeのConnection-Allowlistは、ページが外へつなぐ先をヘッダーで決める仕組みで、仕様はまだ草案 ── つなぎ先の一覧を作り、報告専用のヘッダーで試す前に確認する13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — Chromeの告知は、ページが外へつなぐ先を、ヘッダー1本で決める仕組みだと書いている
   1. 告知が書いた3つのこと
   2. 仕様の文書は、まだ標準ではない
   3. 「サイトの側で決める」とは何か
2. 02 なぜ・背景 — CSPは「何を読み込むか」の道具で、「どこへつなぐか」を全部は覆えない、と告知は書く
   1. 告知が挙げた困りごと
   2. 仕様の説明が挙げた3つの理由
   3. CSPとの違いを表にする
   4. 併用すると、どうなるか
3. 03 この記事に出てくる用語
   1. Connection-Allowlist（ヘッダー）
   2. Connection-Allowlist-Report-Only（報告専用のヘッダー）
   3. URLPattern（URLの型）
   4. response-origin（応答の出どころ）
   5. Reporting-Endpoints（報告の受け皿の名前）
   6. 持ち出し（exfiltration）
4. 04 型別 — 書き方は4つの部品で、止まるものと止まらないものを分けて覚える
   1. 適用範囲: 文書とワーカーの通信が対象
   2. 書き方の部品は4つ
   3. 落とし穴は4つある
   4. 落とし穴1: 一覧は、先頭の1つしか使われない
   5. 落とし穴2: WebSocketは、wsやwssではなく、httpとhttpsで書く
   6. 落とし穴3: 文脈ごとの宣言で、サイト全体ではない
   7. 落とし穴4: 転送は、先が許可リストの中でも止まる
   8. 試すときに見る場所と、報告専用の考え方
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 強制の形のほかにも、5つの選び方がある
   1. 選び方を表にする
   2. CSPのconnect-srcで、通信先を絞る
   3. 見送る判断も、正しい
7. 07 当サイトの場合 — この記事の手順で、つなぎ先の一覧づくりから始める
   1. 当サイトも、この記事の手順で、一覧を作るところから始める
   2. HTMLを読むだけでは、一覧は足りない
   3. 確かめていないこと
8. 08 このテーマは、ここまで
   1. 2026年9月23日 — Chromeの告知
   2. これから
9. 09 この記事のまとめ

01 何が書いてあるか — Chromeの告知は、ページが外へつなぐ先を、ヘッダー1本で決める仕組みだと書いている

告知が書いた3つのこと

Chrome for Developersのブログに、「Connection allowlists: Secure your web application's network access」（訳: 接続の許可リスト: ウェブアプリのネットワークへの出入りを守る）という告知が載っている。ページには、公開日として「September 23, 2026」（2026年9月23日）と書かれている。告知は、新しい仕組みを、冒頭で次のように紹介する。

"Chrome 152 introduces connection allowlists, a new security mechanism that lets you create a strict network sandbox for your documents and workers."

（訳: Chrome 152は、接続の許可リストを導入する。これは、文書とワーカーのために、厳しいネットワークの砂場を作れる、新しいセキュリティの仕組みである。）

ここから読み取れるのは、仕組みの名前が「接続の許可リスト（connection allowlists）」で、サーバーのヘッダーで指定すること、対象が「文書とワーカー」（表示されるページと、その裏で動く処理）であること、版の番号がChrome 152であること、の3つである。

告知の後半には、版についてもう1文ある。

"The connection allowlists feature is officially available starting in Chrome 152."

（訳: 接続の許可リストの機能は、Chrome 152から正式に使える。）

この記事では、版と日付は、この告知のページに書かれたものだけを書く。Chrome 152がいつ安定版になるかは、告知のページには書かれていなかったので、書かない。手元のChromeの版は、chrome://versionで確かめられる（05章の7番目）。

仕様の文書は、まだ標準ではない

告知は、「Connection Allowlists specification」（接続の許可リストの仕様）へのリンクを載せている。リンク先は、WICG（Web Platform Incubator Community Group）が公開している文書で、ページには「Draft Community Group Report, 6 October 2026」（コミュニティグループの報告の草案・2026年10月6日）と書かれている。同じページは、位置づけを次のように書く。

"It is not a W3C Standard nor is it on the W3C Standards Track."

（訳: これはW3Cの標準ではなく、W3Cの標準化の道筋にも載っていない。）

つまり、Chromeが機能を導入する一方で、仕様はコミュニティの草案の段階である。草案は、書き直されうる。この記事の04章で扱う細かい動き（転送の扱いなど）は、2026年10月6日の草案に書かれたものであり、あとで変わる可能性を、頭に置いて読んでほしい。

「サイトの側で決める」とは何か

ブラウザは、ページを表示するとき、スクリプトの取得、画像の読み込み、解析の送信など、たくさんの通信を行う。その通信先を、ページを配るサイトの側が、応答ヘッダーで先に宣言するのが、この仕組みである。告知は、動きをこう書く。ブラウザが通信の門番になり、宣言にない先への接続を、接続を作る前に止める。

サイトを運営する側にとっての意味は、自分のページが、どこへつながっているかを、自分で言い切る必要が出ることである。言い切るには、まず今のつなぎ先を一覧にしなければならない。05章は、その作り方と、報告だけ受ける試し方を、13項目にしている。

02 なぜ・背景 — CSPは「何を読み込むか」の道具で、「どこへつなぐか」を全部は覆えない、と告知は書く

告知が挙げた困りごと

告知は、困りごとを次のように始める。現代のウェブアプリは、外部のスクリプトや、生成AIが作ったコードを取り込むことがある。便利だが、情報が外へ漏れる危険が増える。告知は、CSP（Content Security Policy）との関係を、こう書く。

"While Content Security Policy (CSP) is a powerful tool for controlling what a page can load and execute, it is not designed to restrict where a page communicates."

（訳: CSP（コンテンツ・セキュリティ・ポリシー）は、ページが読み込み実行できるものを制御する強力な道具だが、ページがどこと通信するかを制限するようには設計されていない。）

CSPの役割は、MDNの案内が最初に書いている。

"The primary use case for CSP is to control which resources, in particular JavaScript resources, a document is allowed to load."

（訳: CSPの主な使い道は、文書が読み込んでよい資源、とくにJavaScriptの資源を、制御することである。）

つまりCSPの中心は、何を読み込み、何を実行してよいかである。通信先を絞る指定（connect-src）もあるが、MDNの説明は、その指定が制御する対象を、スクリプトの窓口で読み込むURLだと書く（06章で扱う）。

仕様の説明が挙げた3つの理由

WICGのリポジトリの説明と、仕様の文書の1.2節は、CSPがあるのに別の仕組みを作る理由を、3つ挙げている。見出しだけを、そのまま引く。

"CSP’s model is too granular"

（訳: CSPのモデルは、細かく分けすぎている。）

"CSP’s syntax is not granular enough"

（訳: CSPの書き方は、十分に細かくない。）

"CSP’s coverage is incomplete"

（訳: CSPの覆う範囲は、完全ではない。）

1つ目は、情報が漏れる経路として見ると、画像でもフォントでも同じように危ないのに、CSPは種類ごとに指定を分ける、という指摘である。2つ目は、CSPのホストの書き方が長くなりやすい、という指摘である。3つ目は、CSPが網羅しない通信がある、という指摘で、告知は例として、DNSの先読み、ページの移動、WebRTCを挙げている。

CSPとの違いを表にする

違いを表にする。列の中身は、告知と仕様の説明の記述に、筆者の整理を足したものである。

併用すると、どうなるか

すでにCSPを入れているサイトにとって気になるのは、2つを同時に付けたらどうなるか、である。WICGのリポジトリの説明は、複数の仕組みを重ねたときの扱いを、こう書く。

"each should take effect, and connections will only be established if they pass all of the applicable policies."

（訳: それぞれが効き、接続は、当てはまるすべての方針を通ったときにだけ作られる。）

告知も、既存のCSPに段階的に足す使い方を想定している。

"This feature can be used as a progressive enhancement to an existing Content Security Policy (CSP) based setup."

（訳: この機能は、すでにCSPで組まれた構成に、段階的な強化として使える。）

入れるかどうかは、05章の一覧を作ってから決める。

03 この記事に出てくる用語

Connection-Allowlist（ヘッダー）

ページが外へつなぐ先の一覧を、サーバーが応答ヘッダーで宣言するための名前である。一覧にない先への接続を、ブラウザが止める。

Connection-Allowlist-Report-Only（報告専用のヘッダー）

一覧の外への接続を、止めずに、報告だけ送るための名前である。試すときは、こちらから始める（04章）。

URLPattern（URLの型）

URLの形を、ワイルドカードなどで書くための書き方である。MDNは、この書き方の説明の冒頭に、次のように書く。

"The URL Pattern API defines a syntax that is used to create URL pattern matchers."

（訳: URLパターンのAPIは、URLの型の照合器を作るために使う書き方を定めている。）

response-origin（応答の出どころ）

一覧の中に書ける特別な印で、そのページを配ったサイト自身のオリジン（アドレスの、「https://」からポート番号までの部分）を表す。自分のサイトへの通信を許すときに使う。

Reporting-Endpoints（報告の受け皿の名前）

違反の報告を、どのアドレスへ送るかに、名前を付けるヘッダーである。報告は、ブラウザの報告のAPI（Reporting API）を通して送られる。報告専用のヘッダーのreport-toの指定は、この名前を指す。MDNは、受け皿のアドレスについて、次のように書く。

"non-secure endpoints are ignored"

（訳: 安全でない（httpsでない）受け皿は、無視される。）

持ち出し（exfiltration）

ページの中のスクリプトなどが、利用者の情報を、本来の送り先でない外部へ送ってしまうことをいう。

04 型別 — 書き方は4つの部品で、止まるものと止まらないものを分けて覚える

適用範囲: 文書とワーカーの通信が対象

対象は、告知の言葉では「文書とワーカー」である。仕様の説明は、守る相手を、情報の持ち出しに使える通信の経路に絞っている。

一方、仕様の文書は、守らないものも書いている。次の1文は、その中心である。

"It does not aim to prevent (or even substantially mitigate) threats like content injection or cross-site scripting."

（訳: コンテンツの差し込みや、クロスサイトスクリプティングのような脅威を、防ぐ（大きく和らげる）ことも、目指していない。）

つまり、悪い書き込みを入れさせない仕組みではなく、入ってしまったときの被害を、通信の面で狭める仕組みである。仕様の文書は、同じ箇所で、この仕組みが防御の1つの層であり、これだけでは足りないと書く。

書き方の部品は4つ

ヘッダーの値は、1つの括弧の中に、許す先を並べ、そのあとに、設定をセミコロンで足す形である。告知と仕様の文書から、部品を表にまとめる。

告知は、転送とWebRTCの既定の動きを、次のように書く。

"By default, connection allowlists block all redirects and WebRTC connections."

（訳: 既定では、接続の許可リストは、すべての転送とWebRTCの接続を止める。）

書き方の形は、筆者が作った例で示す。ドメインは、例として使える「example」の名前にしてある。

Reporting-Endpoints: allowlist-reports="https://reports.example.org/r"
Connection-Allowlist-Report-Only: (response-origin "https://cdn.example.com/*" "https://analytics.example.net/*"); report-to=allowlist-reports

1行目で、報告の受け皿に名前を付ける。2行目で、自分のサイトと、2つの外部のサイトだけを許す一覧を、報告専用の形で付ける。ここに書いた3つの先以外へのつなぎ先が出れば、報告が送られる。

落とし穴は4つある

仕様の文書は、実際に入れたあとで、意外に感じやすい動きも書いている。要点を、4つに分ける。

落とし穴1: 一覧は、先頭の1つしか使われない

"Servers may deliver a list with an arbitrary number of items, but only the first will be used."

（訳: サーバーは、いくつでも項目のあるリストを送ってよいが、使われるのは最初の1つだけである。）

ヘッダーの値に、複数の括弧を並べても、2つ目以降は効かない。許す先は、1つの括弧の中にまとめる。

落とし穴2: WebSocketは、wsやwssではなく、httpとhttpsで書く

"WebSocket connections are covered by http and https patterns, not by patterns specifying ws or wss schemes."

（訳: WebSocketの接続は、httpとhttpsの型で覆われ、wsやwssを指定する型では覆われない。）

チャットなどでWebSocketを使っているサイトは、一覧に「wss://…」と書いても効かない。「https://…」の形で書く。

落とし穴3: 文脈ごとの宣言で、サイト全体ではない

"the mechanism is context-specific, not origin-wide."

（訳: この仕組みは、文脈ごとのもので、オリジン全体に効くものではない。）

同じサイトの、制限のゆるい別のページや、ウィンドウから、制限を回られる可能性が、仕様の文書の6.1節に書かれている。告知も、信頼できないコードは、専用のiframeに閉じ込めてから、そのiframeにだけヘッダーを付けるよう勧めている。告知の注意書きは、次のとおりである。

"isolate untrusted code within a dedicated iframe and apply the Connection-Allowlist header exclusively to that iframe."

（訳: 信頼できないコードは、専用のiframeの中に隔離し、Connection-Allowlistのヘッダーを、そのiframeだけに付ける。）

落とし穴4: 転送は、先が許可リストの中でも止まる

仕様の文書は、転送の扱いを、はっきり書く。

"by default, redirect responses regardless of destination will be blocked."

（訳: 既定では、転送の応答は、行き先にかかわらず、止められる。）

たとえば、短縮されたアドレス、決済会社への入口、外部のログインの入口は、転送を挟むことが多い。一覧にそのアドレスを書いても、転送を含むと止まる可能性がある。転送を許すredirects=allowは、行き先の安全の責任が、サーバー側に移る、と仕様の文書は書く。また、値に知らない語を書くと、許す扱いになる、とも書く。値の打ち間違いは、止めるつもりの転送を、通してしまう。05章の11番目で、自サイトに転送を挟む通信がないかを数える。サービスワーカーやDNSの扱いなど、ほかの注意点は、仕様の文書の6章に書かれている。

試すときに見る場所と、報告専用の考え方

告知は、開発用のサーバーでヘッダーを付け、開発者ツールで結果を見る、と書く。見る場所は、次のとおりである。

"Open Chrome DevTools and check the Network panel for requests that are blocked, or the Issues tab for detailed header parsing reports."

（訳: Chrome DevToolsを開き、ネットワークの欄で止められた要求を見るか、Issuesの欄でヘッダーの解析の詳しい報告を見る。）

強制の形では、止まった要求がネットワークの欄に出る。報告専用の形では、止まらないので、ネットワークの欄には出ない。かわりに、Issuesの欄でヘッダーの書き方の誤りを見て、報告の受け皿に届いた違反を数える。告知は、報告専用の形を、こう説明する。

"This parses the policy and sends violation reports to a specified Reporting API endpoint without blocking the connections."

（訳: これは、方針を解析し、接続を止めずに、指定された報告のAPIの受け皿へ違反の報告を送る。）

報告専用の考え方は、CSPにもある。MDNは、CSPの報告専用のヘッダーを、こう説明する。

"The HTTP Content-Security-Policy-Report-Only response header helps to monitor Content Security Policy (CSP) violations and their effects without enforcing the security policies."

（訳: HTTPのContent-Security-Policy-Report-Onlyの応答ヘッダーは、CSPの違反とその影響を、方針を強制せずに、監視する助けになる。）

CSPの報告専用の形に慣れているサイトは、同じ流れで進められる。まず報告だけ受け、報告を読み、一覧を直し、最後に強制へ切り替える。切り替えるかどうかは、05章の13番目で、日付と理由と担当者を残して決める。

05 明日、自社のサイトで確認できることチェックリスト

以下は、担当サイトの外へのつなぎ先を一覧にして、Connection-Allowlistを入れる前の準備を済ませるための13項目である。1〜5番目はつなぎ先の一覧づくり、6〜9番目は今のヘッダーと対応状況、10〜13番目は試験環境での報告専用の試しと、判断である。1項目は5分以内でできる。10番目と12番目の間には、待ち時間が入る。待つ日数は、筆者の目安で7日にした（原典が決めた日数ではない。訪問の少ないサイトは長めに、多いサイトは短めにしてよい）。10番目は、本番ではなく、試験環境で行う。チェックの状態は、ブラウザに保存され、サーバーには送られない。

• 担当サイトの、トップページと、問い合わせまたはログインの画面と、記事または商品の画面の、3ページのアドレスを書き出す
• 3ページのそれぞれを、Chromeの開発者ツールのネットワークの一覧で再読み込みして、ドメインの列を、重複を除いて書き出し、3ページ合計のドメインの数を書く
• 書き出したドメインを、自社、解析・タグ、広告、フォントと部品の配信、埋め込み、決済・ログイン連携の6つに分けて、分けられなかったドメインの数を数える
• 分けられなかったドメインのそれぞれについて、タグの管理画面かテンプレートの検索で、入れた人を探し、持ち主の名前を一覧の横に書く
• 3ページのうち1ページで、最後までスクロールし、フォームの入力欄を1つ選んだあとに、増えたドメインの数を書き留める
• 3ページの応答ヘッダーを開き、Connection-AllowlistとContent-Security-Policyの2つの名前があるかを、ページごとに「有・無」で書く
• 手元のChromeの版を、chrome://versionで確かめ、152以上かどうかを書き留める
• アクセス解析で、直近28日のブラウザ別の訪問の割合を、上位5つ書き出し、Chromeの割合を書き留める
• 違反の報告を受け取るアドレスを1つ決め、httpsで始まっているかを確かめる
• 試験環境の1ページに、一覧に書いたドメインだけを許す報告専用のヘッダーを付け、再読み込みしたあと、開発者ツールのIssuesの欄に、ヘッダーの解析の報告が出ていないかを見る
• ログイン連携、決済、短縮アドレスなど、転送を挟む通信を、3ページで数え、見つかった数を書く
• 報告専用のヘッダーを付けて、決めた日数（筆者の目安は7日）がたったら、受け皿に届いた報告のドメインの数と、一覧にないものの数を、書き出す
• 強制に切り替えるか、見送るかを、日付・理由・担当者の名前を付けて、1行で書く

2番目と5番目の作業は、DevToolsの画面で行う。ネットワークの一覧には、ドメインの列がある。DevToolsの文書は、その列を次のように説明する。

"Domain. The domain part of the URL."

（訳: ドメイン。URLのうちのドメインの部分。）

6番目の確認は、当サイトの無料ツールの1つ、🔧 WEBサイト総合分析・レポートツールでも、確かめられる。このツールのページの説明は、診断の項目として、HTTPS対応とセキュリティヘッダー（HSTS・CSP・X-Frame-Options）を挙げている。ただし、この記事のConnection-Allowlistを見分けるかは、確かめていない。ツールの結果に載っていなくても、ヘッダーが付いていない証拠にはならない。ブラウザの開発者ツールで、自分の目で確かめる。

10番目の試しの前後で、画面の崩れがないかを、見た目で比べたいときは、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールが使える。ヘッダーの動きそのものは、写真には写らないので、通信の確認は、開発者ツールで行う。

06 代替・他の選択肢 — 強制の形のほかにも、5つの選び方がある

選び方を表にする

表の「出典」の列は、書かれている範囲を示す。「筆者の整理」とあるものは、記事の筆者の考えである。

CSPのconnect-srcで、通信先を絞る

通信先を絞るだけなら、すでにある道具もある。MDNは、connect-srcの役割を、次のように書く。

"The HTTP Content-Security-Policy (CSP) connect-src directive restricts the URLs which can be loaded using script interfaces."

（訳: HTTPのCSPのconnect-src指示は、スクリプトの窓口を使って読み込めるURLを制限する。）

MDNは、対象として、aタグのping属性、fetch()、fetchLater()、XMLHttpRequest、WebSocket、EventSource、Navigator.sendBeacon()を挙げている。同じ説明の中に、「Baseline Widely available」（広く使える）という表示があり、2016年11月から複数のブラウザで使えると書かれている。connect-srcは、MDNが「広く使える」と表示している。Connection-Allowlistは、告知がChrome 152からと書くだけで、他のブラウザについては、この記事では確かめていない。

見送る判断も、正しい

Connection-Allowlistは、Chromeが導入した新しい仕組みで、仕様は草案である。他のブラウザの扱いは、この記事では確かめていない。訪問の多くがChromeでないブラウザからであれば、そのブラウザで効くかを、先に確かめる必要がある。05章の8番目で、割合を確かめる。

見送るときも、つなぎ先の一覧と持ち主は、手元に残す。見送ったことと、その理由と、次に見直す日を、1行残す（05章の13番目）。

07 当サイトの場合 — この記事の手順で、つなぎ先の一覧づくりから始める

当サイトも、この記事の手順で、一覧を作るところから始める

当サイトも、この記事の05章の手順どおり、つなぎ先の一覧を作るところから始める。ヘッダーを付けるかどうかは、一覧と持ち主がそろってから、報告専用の形で試して決める。

HTMLを読むだけでは、一覧は足りない

当サイトの公開ページのHTMLから、スクリプト、画像、フォント、スタイルシートなどを呼ぶタグを読めば、外のドメインは数えられる。これは、05章の2番目の作業の、一番簡単な形である。ただし、HTMLに書かれた先は、つなぎ先の一部にすぎない。スクリプトが、動いた後に別の先を呼ぶ通信は、HTMLのタグには出てこない。インラインのスクリプトの中には、HTMLのタグとして読まれないドメイン名が書かれていることもある（構造化データの名前空間のように、通信先ではないものも混ざる）。本当のつなぎ先の一覧は、ブラウザの開発者ツールで、ページを動かして取るしかない。

サーバーが外へつなぐ先の一覧を作り、月に1回、見直す、という話は、当サイトのブログ記事「認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録」に書いた。ブラウザの通信とは別の話だが、一覧と持ち主を、決まった間隔で見直す、という考え方は同じである。

確かめていないこと

• 開発者ツールでの、動いた後の通信の一覧 — この記事では取っていない
• Chrome 152での、ヘッダーの実際の動き — 当サイトで、試していない
• ChromeStatusの機能ページ — 告知から辿れるページだが、JavaScriptで描かれる画面で、取得したHTMLから本文を読めなかった
• Chrome以外のブラウザでの扱い — 確かめていない

08 このテーマは、ここまで

2026年9月23日 — Chromeの告知

Chrome for Developersのブログが、Connection allowlistsを告知した。Chrome 152で正式に使えると書き、仕様、WICGのリポジトリ、ChromeStatusへのリンクを載せた。仕様の草案の日付は、2026年10月6日である。

これから

この記事は、2026年10月26日に、11の出典のページを確かめた（ChromeStatusの機能ページは、本文を読めなかったので数えていない）時点のものである。Chrome 152の安定版への移行、他のブラウザの対応、仕様の変更が確かめられたときは、日付つきで、この記事に追記する。