【ITニュース解説】Every Origin Your Page Talks To, and the Four Traps in Listing Them

ウェブサイトを運営する上で、自分のページがどのような外部サービスと通信しているかを正確に把握することは非常に重要だ。最近、AppleのウェブブラウザSafariが、特定の種類のサードパーティ（第三者）ドメインとの通信を、ネットワークレベルで自動的にブロックする機能を標準で有効にした。これにより、自分たちのウェブページがそうしたブロック対象となるサードパーティと通信していないかを確認する必要性が高まっている。

しかし、多くのチームがこの問いに正確に答えることができないのが現状だ。これは、彼らが不注意なのではなく、外部サービスとの連携が「タグマネージャー」や「マーケティングベンダー」といったツールを通じて行われるため、その設定がコードではなく設定ファイルで管理されていることに原因がある。そのため、ソースコードを読んだだけでは全ての外部連携を把握できず、デプロイ（更新）なしに連携先が変わる可能性もある。

ウェブページが通信している外部オリジン（ウェブサイトのドメインやポート番号など、その出所を識別する情報）のリストを実際に取得する方法はいくつか存在するが、それぞれに落とし穴がある。

最も手軽な確認方法として、ブラウザの開発者ツールにある「ネットワークパネル」を使う方法がある。これは、特定のページを読み込んだ際の通信履歴を一覧で表示してくれるため、今見ているページがどの外部オリジンと通信しているかを一目で確認できる。しかし、この方法は、自分のマシンで、たまたま通ったパス（経路）で、自分のブラウザ拡張機能やクッキーの状態に依存した結果しか得られない。例えば、ログインしているユーザーがチェックアウトページを訪れたときだけ発生するような通信は、この方法では見逃してしまう可能性があるため、完全な監査には不十分だ。

より精度の高いローカルでの確認方法として、「Resource Timing API」というブラウザの機能がある。これは、ウェブページが実際に読み込んだリソース（画像、スクリプト、XMLHttpRequestsなど）のリストをプログラム的に取得できるもので、クロスオリジン（異なるオリジン）のリソースも正確に列挙できる。具体的には、performance.getEntriesByType('resource')というJavaScriptコードを使うことで、取得したリソースのオリジンを抽出できる。この方法では、リソースの取得時間に関する詳細なデータの一部が制限されることがあるが、必要なのはオリジン名だけであれば問題なく機能する。

このResource Timing APIを使う際の第一の落とし穴は、そのバッファサイズが小さいことだ。MDN Web Docs（ウェブ技術の公式ドキュメント）によれば、デフォルトでは最大250件のリソースタイミングエントリしか記録されない。多くのリソースを読み込む重いページでは、この上限を簡単に超えてしまい、失われたエントリに関する警告などは表示されない。もし全てのリソースのオリジンを確実に取得したい場合は、PerformanceObserverというAPIを使って、リソースの読み込みを継続的に監視する必要がある。これによって、バッファサイズに制限されずに全てのエントリを取得できるようになる。

上記の方法はすべて、自分の手元の環境で実行されるため、実際のユーザーが訪れる全てのページや環境をカバーすることはできない。全てのページと全ての実際の訪問者を網羅して外部連携を把握するには、HTTPレスポンスヘッダーを利用する方法が有効だ。

その一つが、「Content-Security-Policy-Report-Only（CSP-Report-Only）」ヘッダーを用いる方法だ。MDNの説明によると、これはウェブページのセキュリティポリシーであるCSPの「違反を監視し、その影響をポリシーを強制することなく確認する」ことを目的としている。この仕組みを逆手にとって、意図的に「すべての通信は自社のオリジンのみに制限する（connect-src 'self'）」という、実際には不正確なポリシーを宣言する。すると、このポリシーに違反する、つまり自社オリジン以外の外部への接続が全てレポートとして収集される。このレポートは、実際のユーザーのブラウザから、普段はアクセスしないようなページも含めて送信されるため、実世界の利用状況を反映した正確なリストが得られる。

しかし、このCSP-Report-Onlyにもいくつかの落とし穴がある。第二の落とし穴は、「report-toディレクティブ」の欠如だ。CSPのレポートを送信するには、レポートの送信先を明示するreport-to csp-endpointのようなディレクティブが必須となる。これが設定されていない場合、レポートは一切送信されない。そして、ポリシーが何一つ違反されていないかのように見えてしまうため、問題が静かに見過ごされてしまう。

第三の落とし穴は、report-toディレクティブのブラウザサポート状況だ。report-toは比較的新しいディレクティブであり、まだ全ての主要なブラウザで完全にサポートされているわけではない。MDNの例でも、report-toが推奨されつつも、以前のreport-uriディレクティブも併記されている。もし新しいreport-toだけを設定した場合、一部のブラウザからのレポートしか収集できず、他のブラウザでは問題がないと誤解してしまう可能性がある。完全なカバレッジを得るためには、両方を設定することが推奨される。

第四の落とし穴は、このCSP関連ヘッダーを<meta>タグ内で指定できないことだ。MDNは、「このヘッダーは<meta>要素内でサポートされていない」と明言している。もしHTTPレスポンスヘッダーの設定が困難な環境であったとしても、<meta>タグでの代替策は silently ignored（静かに無視）されてしまい、機能しない。

これらの落とし穴を乗り越えて外部オリジンのリストを事前に把握しておくことには、大きな価値がある。ウェブサイトが依存している外部サービスは、ブラウザのデフォルト設定、ユーザーのブラウザ拡張機能、企業のセキュリティ製品、プロキシサーバー、あるいはネットワークの設定など、さまざまな理由で突然機能しなくなる可能性がある。

そのような事態が発生した際、その通信はユーザーのブラウザでブロックされるため、自社のサーバーには何も情報が届かない。サーバーのログは完全に見えても、実際の問題を特定する役には立たない。結果として、「登録できなかった」「購入手続きが進まない」といった漠然としたユーザーからの問い合わせが来るだけで、サードパーティが原因であることはユーザーも認識できない。事前に正確な外部オリジンのリストを持っていれば、そのような問題が発生した際に、それが謎の現象として終わるか、あるいは迅速に原因を特定して解決できるかの大きな違いとなる。このリストの作成には一度だけ手間がかかるが、いつか外部サービスが突然利用できなくなるという事態に直面した際に、その原因をゼロから探すという大変な作業を避けることができる。