テック技報最新号へ →
コード

Connection-Allowlist ヘッダで、ページが通信できる先をブラウザに制限させる（Chrome 152〜）

レスポンスヘッダ Connection-Allowlist に URL パターンを並べると、そのページ（やワーカー）から出る通信をブラウザが「許可リスト以外は全部拒否」にする。CSP と違ってリクエストの種類ごとではなく、通信そのものを止められる。

@zaru · 投稿 2026-10-20
#security#frontend#http-header#chrome#supply-chain

どんな時に使う？

  • 第三者のスクリプトや広告タグ、埋め込みゲームを載せていて、乗っ取られたときに情報を外へ送られたくない
  • AI が生成したコードや、ユーザーが書いたコードをページ内（サンドボックス）で動かす
  • 「このページは自社の API としか話さない」という境界を、アプリのコードではなくブラウザに守らせたい

書き方

http
# 自分のオリジンと API だけ許可
Connection-Allowlist: ("https://api.example.com/*" response-origin)

# リダイレクトと WebRTC は既定で拒否。必要なら明示的に許可
Connection-Allowlist: ("https://api.example.com/*"); redirects=allow; webrtc=allow

# まずは止めずに違反だけ報告させる（Reporting-Endpoints ヘッダで送り先を定義）
Reporting-Endpoints: security-endpoint="https://example.com/reports"
Connection-Allowlist-Report-Only: ("https://trusted.com/*"); report-to=security-endpoint
  • パターンは URLPattern の構文。response-origin は「このレスポンスを返したオリジン」を表すトークン。
  • ポリシーはウィンドウやワーカーごとに別々にかかる。

おすすめの入れ方

  • いきなり本番のトップページに付けると、自分のコードの通信まで止めかねない。信頼できないコードは別オリジンか sandbox 付きの iframe に隔離し、その iframe のレスポンスにだけ付けるのが公式のおすすめ（同じオリジンだとスクリプト経由で抜けられる）。
  • 最初は -Report-Only で数日動かし、報告を見てから本番適用する。
  • 確認は DevTools の Network パネル（ブロックされたリクエスト）と Issues タブ（ヘッダの書き間違い）。

注意点

  • 2026-10 時点で対応は Chrome 152 以降。Firefox と Safari は未対応なので、非対応ブラウザでは何も起きない（壊れはしない）。CSP の置き換えではなく、CSP に重ねる追加の防御として使う。
  • CSP の connect-src などでは止められない通信（DNS プリフェッチ、ナビゲーション、WebRTC など）も対象になるのが CSP との違い。

出典

X の元の投稿を開く