Azure Cosmos DBの公式更新情報「Fix the empty string referrer for firefox 150+」は、データベース本体やSDKの仕様変更ではなく、Azure Cosmos DB Data ExplorerがAzure Portal内で読み込み中のまま止まる可能性を減らすUI側の修正です。特に、Firefox 150+や厳格なプライバシー設定、コンテンツブロック拡張機能、制限の強いReferrer-Policyによってdocument.referrerが空になる環境では確認しておきたい内容です。PRでは、空のreferrerによりpostMessageの送信先オリジンを決められず、ログ処理が再帰して「too much recursion」が発生し、Data Explorerの準備完了ハンドシェイクが送られない問題が説明されています。(GitHub)
管理者がまず見るべきポイントは、Cosmos DBアカウントのネットワーク設定やRU、インデックス、アプリケーションコードではありません。Azure Portal上のData Explorer表示、ブラウザポリシー、拡張機能、そして自社でCosmos Explorerを組み込んでいる場合のiframe連携です。
今回の変更で何が変わるのか
Azure Cosmos DB Data Explorerは、Azure Cosmos DBに格納されたデータを表示・管理するためのWebベースのインターフェイスです。Microsoft Learnでも、Azure Portal内のData Explorer体験と、専用のData Explorerを使う方法が案内されています。(Microsoft Learn)
今回の修正対象は、そのData ExplorerがAzure Portal内のiframeとして動作するときのメッセージ送信処理です。Azureのcosmos-explorerリポジトリは、Azure Portal、専用Data Explorer、Cosmos DB EmulatorのUIを支えるプロジェクトとして公開されています。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 修正対象 | Azure Cosmos DB Data ExplorerのpostMessage送信処理 |
| 主な発生条件 | document.referrerが空になるブラウザ環境、厳格なプライバシー設定、コンテンツブロック、制限の強いReferrer-Policy |
| 修正前の問題 | 送信先オリジンを決められず、ログ処理が同じ送信経路に入り直して再帰し、Data Explorerが読み込み中のままになる可能性があった |
| 修正後の挙動 | document.referrerが空の場合、iframe URLに含まれるtrustedAuthorityをフォールバックとして使い、厳密なoriginに正規化する |
| 利用者側の移行 | 通常、Cosmos DBのデータ移行、SDK更新、スキーマ変更は不要 |
| 開発者側の確認 | 自社でcosmos-explorerをビルド・埋め込み利用している場合は、該当修正を取り込んでテストする |
関連PR #2486は2026年5月20日にmasterへマージされ、変更ファイルはsrc/Common/MessageHandler.tsです。差分では、document.referrerだけに依存せず_getPortalTargetOriginで送信先を決定する処理と、失敗時にLogger経由ではなくApplication Insightsへ直接送る処理が追加されています。(GitHub)
問題の原因：空のdocument.referrerでpostMessageの送信先を決められない
window.postMessage()は、iframeと親ページなど、異なるWindow間で安全にオリジン間通信を行うためのWeb APIです。targetOriginには送信先のオリジンを指定でき、意図しない相手にメッセージを渡さないための重要な制御になります。MDNも、*ではなく具体的なtargetOriginを指定する重要性を説明しています。(MDN 웹 문서)
Azure Portal内のData Explorerはiframeとして読み込まれるため、Data Explorer側から親のAzure Portalへメッセージを送る必要があります。従来の処理では、その送信先としてdocument.referrerを利用していました。しかし、ブラウザがreferrer情報を空にすると、送信先オリジンを取得できません。
referrerが空になる理由は、Firefox 150+だけに限定して考えるべきではありません。PR本文では、Firefoxの動的な状態分離やETP Strict、コンテンツブロック拡張機能、制限の強いReferrer-Policyヘッダーなどが例として挙げられています。(GitHub)
Referrer-Policyは、リクエスト時に送信されるreferrer情報の量を制御するHTTPヘッダーです。no-referrerではreferrer情報が送られず、same-originではクロスオリジンのリクエストにreferrerが送られません。つまり、セキュリティやプライバシーを強める設定が、iframe連携の前提を崩すことがあります。(MDN 웹 문서)
影響範囲：Cosmos DB本体ではなく管理UIが中心
今回の変更は、Azure Cosmos DBのデータプレーンではなく、Data Explorerの表示・操作体験に関わる修正です。アプリケーションからの読み取り、書き込み、クエリ、SDK接続、RU消費、インデックス設定、バックアップ、変更フィードなどが直接変更されるわけではありません。
| 影響を受けやすいケース | 起きやすい現象 | 確認ポイント |
|---|---|---|
| Azure Portal内でData Explorerを開く | 読み込みスピナーのまま止まる | Firefoxのバージョン、プライバシー設定、拡張機能 |
| 社内標準ブラウザでreferrerを抑制している | 一部ユーザーだけData Explorerが開けない | グループポリシー、ブラウザ管理ポリシー |
| コンテンツブロッカーを利用している | ポータル内iframe通信が失敗する | 拡張機能の無効化で再現性が変わるか |
| 自社でCosmos Explorerを組み込んでいる | iframe連携や親画面との通信が不安定 | trustedAuthorityの付与、origin検証、エラー処理 |
| E2EテストでPortal埋め込みを検証している | 特定ブラウザだけテストが落ちる | referrerpolicy="no-referrer"相当のテスト追加 |
一方で、Cosmos DBアカウントのファイアウォール、プライベートエンドポイント、ロール割り当て、CORS、接続文字列、API種別を最初に変更するのは避けるべきです。Data Explorerが開けない症状だけを見てネットワークや権限を緩めると、根本原因から外れた変更になりやすく、セキュリティリスクも増えます。
管理者が確認すべき設定と運用ポイント
まずブラウザ起因かを切り分ける
Data ExplorerがAzure Portal上で読み込み中のまま止まる場合は、次の順で切り分けると無駄な設定変更を避けられます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 同じユーザー・同じCosmos DBアカウントを別ブラウザで開く | 特定ブラウザだけで起きるならブラウザ設定の可能性が高い |
| 2 | Firefoxのプライバシー設定を確認する | 厳格な追跡防止や企業管理ポリシーの影響を見る |
| 3 | コンテンツブロック拡張機能を一時的に無効化する | 無効化で改善するなら拡張機能がreferrerやiframe通信に干渉している可能性がある |
| 4 | 専用Data Explorerを試す | Azure Portal内のiframe固有の問題かを分離できる |
| 5 | 開発者ツールのConsoleを確認する | too much recursionやpostMessage関連のエラーがないかを見る |
専用のAzure Cosmos DB Data Explorerは、Azure Portal内のData Explorerとは別の利用経路として案内されています。Microsoft Learnでは、専用Data Explorerが全画面表示やクエリ結果共有などの利点を持つと説明されています。(Microsoft Learn)
セキュリティ設定を安易に弱めない
今回の問題は、referrerが空になることでUI連携が崩れるケースです。ただし、だからといって組織全体のReferrer-Policyを緩めたり、unsafe-urlのような設定へ変更したりするのは慎重に判断すべきです。MDNは、unsafe-urlがHTTPSリソースURLの潜在的にプライベートな情報を安全でないオリジンへ漏らす可能性があると警告しています。(MDN 웹 문서)
恒久対応として優先すべきなのは、ブラウザのプライバシー制御を弱めることではなく、Data Explorer側がreferrerなしでも安全に親Portalのoriginを決定できる状態にすることです。今回の修正はまさにその方向の変更です。
問い合わせ対応では情報を絞って集める
社内ヘルプデスクやAzure管理者は、「Data Explorerが開けない」という問い合わせに対して、次の情報をテンプレート化して収集すると原因特定が早くなります。
| 収集項目 | 例 |
|---|---|
| ブラウザ名とバージョン | Firefox 150+、Edge、Chromeなど |
| プライバシー設定 | 標準、厳格、企業管理ポリシー適用あり |
| 拡張機能 | コンテンツブロック、広告ブロック、セキュリティ製品のブラウザ拡張 |
| 発生場所 | Azure Portal内のData Explorer、専用Data Explorer、Emulator、独自埋め込み |
| エラー | Console上のtoo much recursion、postMessage、origin関連メッセージ |
| 再現条件 | 特定端末のみ、特定テナントのみ、特定ブラウザのみ |
この切り分けを行うと、Cosmos DBアカウント側の障害なのか、ポータルUI・ブラウザ・拡張機能の問題なのかを早い段階で分けられます。
開発者が確認すべき移行・展開ポイント
自社でcosmos-explorerを利用している場合は修正取り込みを確認する
Microsoftが管理するAzure Portalを通常利用しているだけなら、利用者側でData Explorerのコードを直接入れ替えることはできません。一方、自社環境でAzure/cosmos-explorerをビルドしている、独自ポータルにData Explorerを埋め込んでいる、Emulatorや検証環境で独自ホストしている場合は、今回のPR相当の修正が含まれているか確認が必要です。
PRの差分では、document.referrerが存在する場合はそれを使い、空の場合はURLクエリのtrustedAuthorityを読み取ってnew URL(...).originでoriginへ正規化する流れが追加されています。さらに、送信先originが取得できない場合はpostMessageを呼ばず、Loggerを経由しない直接のTelemetry記録で再帰を避ける実装になっています。(GitHub)
実装方針としては、次の3点を満たしているかを確認してください。
| 確認項目 | よい状態 | 避けるべき状態 |
|---|---|---|
| 送信先originの決定 | document.referrerが空でも信頼済みパラメーターからoriginを復元できる | referrerが常に存在すると仮定する |
| originの扱い | スキーム、ホスト、ポート単位のoriginへ正規化する | URL全体や未検証の文字列をそのまま使う |
| エラー記録 | 壊れたpostMessage経路に入らないTelemetryを使う | エラー時に同じ送信関数へ戻るLoggerを呼ぶ |
trustedAuthorityは「便利な抜け道」ではなく信頼境界として扱う
今回の修正で使われるtrustedAuthorityは、Azure Portalがiframe URLに埋め込む信頼済みAuthorityとして説明されています。ここで重要なのは、任意の送信先を許すためのパラメーターではなく、referrerが空でも正しいPortal originを復元するためのフォールバックとして扱うことです。(GitHub)
独自実装で同様の考え方を取り入れる場合は、次のようなルールを設けるべきです。
targetOriginに*を使わないtrustedAuthorityをそのまま文字列連結しない- 許可済みのPortal originと照合する
- パスやクエリではなくoriginだけを使う
- malformed URLの場合は送信せず、Telemetryに残す
- 受信側でも
event.originとメッセージ形式を検証する
MDNは、postMessageでメッセージを受信する側がoriginやsourceで送信者を検証する必要があると説明しています。送信側のtargetOriginだけでなく、受信側の検証も合わせて実装してください。(MDN 웹 문서)
テストでは「referrerがある状態」だけを見ない
今回の不具合は、通常の開発環境では見落としやすい典型例です。多くのローカルテストではdocument.referrerが存在するか、そもそもPortal埋め込みの条件を再現していません。PRでは、referrerpolicy="no-referrer"を使ったラッパーページでローカル再現し、修正前は即座に「too much recursion」、修正後は正常に起動することを確認したと説明されています。(GitHub)
| テストケース | 期待する結果 |
|---|---|
| 通常のreferrerあり | 従来通り親Portalへメッセージを送れる |
referrerpolicy="no-referrer"のiframe | trustedAuthorityからoriginを復元し、Data Explorerが起動する |
trustedAuthorityが不正なURL | postMessageを呼ばず、再帰せずにTelemetryへ記録する |
trustedAuthorityがない | 無限再帰せず、失敗を安全に扱う |
| Firefoxの厳格なプライバシー設定 | 読み込みスピナーで止まらない |
| コンテンツブロック拡張機能あり | 少なくとも再帰エラーでUI全体が固まらない |
| 受信側originが不正 | メッセージを処理しない |
開発者は、正常系だけでなく「ブラウザがセキュリティ・プライバシーのために情報を渡さない」ケースをE2Eテストに含めるべきです。iframe、Portal、埋め込みUIを扱う場合、referrerやcookie、storage、third-party contextの前提は今後も変わる可能性があります。
展開時の注意点：触るべき設定と触らない方がよい設定
Azure Portal利用者はDB設定を先に変えない
Azure PortalのData Explorerだけが開けない場合、最初にCosmos DBアカウントの本番設定を変更するのは避けてください。特に、次の変更は今回の修正内容と直接関係しない可能性が高いです。
| 変更しがちな設定 | 今回の問題との関係 |
|---|---|
| ファイアウォール許可範囲の拡大 | iframeのreferrer問題とは別 |
| プライベートエンドポイントの変更 | Data ExplorerのUI通信とは原因が異なる可能性が高い |
| RBACやキーの再発行 | 認証・認可エラーではなくUI読み込みエラーの場合は優先度が低い |
| RU/sの増減 | 読み込みスピナーやpostMessage再帰とは無関係 |
| CORS設定 | Azure Portal内iframeの親子通信とは別の論点になりやすい |
まずはブラウザ条件、Portal内Data Explorerか専用Data Explorerか、Consoleエラーの有無を確認しましょう。
自社ホスト版はキャッシュとロールバックも考慮する
自社でCosmos Explorerを配布している場合、コード修正を取り込むだけでは不十分です。フロントエンド資産がブラウザやCDNにキャッシュされていると、修正後もしばらく古いJavaScriptが実行されることがあります。
展開時は、次の点を確認してください。
| 項目 | 確認内容 |
|---|---|
| ビルド | PR #2486相当のMessageHandler.ts修正が含まれる |
| 配布 | CDN、App Service、静的ホスティングのキャッシュを更新する |
| 互換性 | 既存Portal埋め込み、専用画面、Emulator表示で動作確認する |
| 監視 | no target origin系のTelemetryが急増していないか見る |
| ロールバック | 修正後に別のorigin判定問題が出た場合の戻し手順を用意する |
特に、独自PortalでData Explorerをiframeに入れている場合は、trustedAuthorityに相当する値を正しく付けているか、許可リストと一致しているかを事前に確認してください。
よくある疑問
Azure Cosmos DBのデータやアプリケーションコードに影響する？
通常は影響しません。今回の修正はData Explorerのiframe通信に関するものであり、Cosmos DBの保存データ、クエリ結果、パーティションキー、インデックス、SDKのAPI仕様を変えるものではありません。アプリケーションからCosmos DBへ直接アクセスしている処理で問題が出ていないなら、まずData Explorer UIの問題として切り分けるのが現実的です。
Firefox 150+以外では関係ない？
Firefox 150+はPRタイトルに含まれる重要な条件ですが、問題の本質は「ブラウザや設定によりdocument.referrerが空になること」です。PR本文でも、FirefoxのETP Strictだけでなく、コンテンツブロック拡張機能や制限の強いReferrer-Policyヘッダーが例として挙げられています。(GitHub)
そのため、EdgeやChromeでも、拡張機能や企業管理ポリシーによってreferrerが抑制される環境では似た症状が起きる可能性があります。
セキュリティ修正として緊急対応すべき？
PRの説明を見る限り、主眼はData Explorerが読み込み中のまま止まる問題と、失敗時の再帰を防ぐ堅牢性改善です。データ漏えい、認証バイパス、CVE対応として説明されているわけではありません。とはいえ、postMessageのorigin指定はセキュリティ上重要な実装ポイントです。*で送る、受信元を検証しない、未検証のURLをtargetOriginに使う、といった実装が自社コードにないかはこの機会に確認すべきです。
一時回避策はある？
Azure Portal内のData Explorerでだけ問題が出る場合は、次の順で試すとよいでしょう。
| 回避策 | 注意点 |
|---|---|
| 別ブラウザで開く | 恒久対応ではなく切り分け用として使う |
| 専用Data Explorerを使う | 権限や共有方法がPortal内利用と異なる場合がある |
| 拡張機能を一時停止する | 組織のセキュリティポリシーに反しない範囲で行う |
| ブラウザのプライバシー設定を一時的に変更する | 恒久的に弱める前に管理者へ相談する |
| Microsoft管理側の更新反映を待つ | 自社でPortal本体のコードを直接更新することはできない |
実務でのチェックリスト
| 対象者 | 今日確認すべきこと | 完了の目安 |
|---|---|---|
| Azure管理者 | Data Explorerが開けない問い合わせがUI起因かを切り分ける | 別ブラウザ・専用Data Explorer・Consoleエラーで分類できている |
| セキュリティ管理者 | referrer抑制ポリシーやブラウザ拡張機能の影響を確認する | セキュリティ設定を弱めずに回避・説明できる |
| 開発者 | 自社のiframe実装やcosmos-explorer取り込み状況を確認する | trustedAuthority相当のfallbackとorigin検証がある |
| QA担当 | referrerpolicy="no-referrer"相当のE2Eテストを追加する | referrerなしでも再帰せず起動できる |
| ヘルプデスク | 問い合わせテンプレートを整備する | ブラウザ、拡張機能、発生場所、Consoleエラーを収集できる |
まとめ：UI不具合として切り分け、必要な環境だけ更新する
今回の「Fix the empty string referrer for firefox 150+」は、Azure Cosmos DBのデータベース機能そのものの変更ではなく、Azure Cosmos DB Data ExplorerがAzure Portal内のiframeから安全にメッセージを送るための修正です。document.referrerが空になっても、trustedAuthorityから送信先originを復元し、失敗時にも再帰しないようにする点が中心です。(GitHub)
管理者は、Data Explorerが開かないという症状を見ても、すぐにCosmos DBのネットワークや権限を変えないことが重要です。まずブラウザ、拡張機能、Portal内表示か専用Data Explorerかを切り分けてください。
開発者は、自社でCosmos Explorerを埋め込み利用している場合に、referrerが存在する前提の実装を見直しましょう。postMessageでは具体的なtargetOriginを指定し、受信側でもoriginとメッセージ形式を検証する。この基本を守ることが、今後のブラウザプライバシー強化にも耐える実装につながります。
コメント