ストレージ パーティショニング

ユーザーのプライバシーを強化し、サイドチャネルによるクロスサイト トラッキングに対抗するため、Chrome ではストレージ パーティショニングと呼ばれるプロセスを通じて、サードパーティのコンテキストでほとんどのストレージ API と通信 API を分離するようになりました。

実装ステータス

この機能は、Chrome 115 以降のすべてのユーザーに対して有効になっています。同様のストレージ分割は、Firefox や Safari などの他の主要なブラウザでも実施または計画されています。GitHub のストレージ パーティショニングに関する提案は、引き続き議論中です。

ストレージ パーティショニングとは

特定の種類のサイドチャネルによるクロスサイト トラッキングを防止するため、Chrome ではサードパーティのコンテキストでストレージ API と通信 API をパーティショニングしています。

ストレージ パーティショニングがないと、サイトは異なるサイト間でデータを結合して、ウェブ全体でユーザーを追跡できます。また、埋め込みサイトは、タイミング攻撃、XS-Leaks、COSI などのサイドチャネル手法を使用して、トップレベル サイトのユーザーに関する特定の状態を推測できます。

これまで、ストレージはオリジンでのみキー付けされていました。つまり、example.com の iframe が a.com と b.com に埋め込まれている場合、ストレージに ID を保存して正常に取得することで、それらの 2 つのサイトでのユーザーの閲覧習慣を学習できます。サードパーティのストレージ パーティショニングが有効になっている場合、example.com のストレージは 2 つの異なるパーティション（1 つは a.com 用、もう 1 つは b.com 用）に存在します。

一般に、パーティショニングとは、iframe 内のローカル ストレージや IndexedDB などのストレージ API によって書き込まれたデータに、同じオリジンを共有するすべてのコンテキストからアクセスできなくなることを意味します。代わりに、そのデータは分離され、同じオリジンと同じトップレベル サイトの両方を共有するコンテキストでのみ使用できるようになりました。

変更前

パーティショニングのない Storage API。
ストレージ パーティショニングの前に、example.com は a.com に埋め込まれているときにデータを書き込み、b.com に埋め込まれているときにデータを読み取ることができました。

変更後

パーティショニングを使用する Storage API。
ストレージのパーティショニング後、example.com が b.com に埋め込まれている場合、a.com に埋め込まれている example.com のストレージにアクセスできなくなります。

連結された iframe でのストレージ パーティショニング

iframe がネストされている場合、特にチェーン内に同じオリジンが複数回出現する場合、ストレージ パーティショニングの複雑さは大幅に増加します。

たとえば、A1 に B の iframe が含まれ、その iframe に A2 の iframe が含まれており、A1 と A2 の両方が同じサイトにある場合です。パーティショニングで最上位サイトと現在のフレームのオリジンのみが考慮されると、iframe A2 は、間にクロスサイト iframe B があるにもかかわらず、最上位サイト（A1）とサイトを共有しているため、誤って「ファースト パーティ」と見なされる可能性があります。A2 がデフォルトでパーティショニングされていないストレージにアクセスできる場合、A2 がクリックジャッキングなどのセキュリティ リスクにさらされる可能性があります。

この問題に対処するため、Chrome ではストレージ パーティション キーに「祖先ビット」が追加されます。このビットは、現在の iframe とトップレベル サイトの間にあるドキュメントが別の（クロスサイト）オリジンからのものである場合に設定されます。この場合、サイト B はクロスサイトであるため、A2 にビットが設定され、そのストレージは A1 からパーティショニングされます。

iframe チェーンが同じサイトのコンテキストのみで構成されている場合（A2 を含むサイト A1 が A3 を含むなど）、祖先ビットはストレージをさらにパーティショニングしません。この場合、ストレージは共有されたままになり、共通のオリジンと最上位サイトによってキーが設定されます。

連鎖された iframe 全体にパーティション化されていないアクセスが必要なサイトの場合、Chrome ではこのユースケースを可能にするために Storage Access API の拡張を試験運用しています。Storage Access API では、フレーム内のサイトが API を明示的に呼び出す必要があるため、クリックジャッキングのリスクを軽減できます。

パーティショニングによる API の変更

パーティショニングの影響を受ける API は、次のグループに分類できます。

ストレージ API

  • 割り当てシステム
    割り当てシステムは、ストレージに割り当てるディスク容量を決定するために使用されます。割り当てシステムは、各パーティションを個別のバケットとして管理し、許可される容量と、その容量が消去されるタイミングを決定します。
    navigator.storage.estimate() メソッドで、ストレージ パーティションに固有の情報が提供されるようになりました。window.webkitStorageInfo や navigator.webkitTemporaryStorage などの Chrome 専用 API は非推奨になりました。
    IndexedDB とキャッシュ ストレージは、パーティション分割された割り当てシステムを使用します。
  • Web Storage API
    Web Storage API は、ブラウザが Key-Value ペアを保存できるメカニズムを提供します。メカニズムは 2 つあります。ローカル ストレージとセッション ストレージです。割り当て管理対象ではありませんが、パーティショニングは行われます。
  • オリジンのプライベート ファイル システム
    File System Access API を使用すると、ユーザーがアクセス権を付与した後、サイトはデバイス上のファイルやフォルダに変更を直接読み取ったり保存したりできます。オリジンのプライベート ファイル システムを使用すると、オリジンはプライベート コンテンツをディスクに直接保存できます。このコンテンツは引き続きユーザーがアクセスできますが、パーティショニングされます。
  • Storage Bucket API
    Storage Bucket API は Storage Standard 向けに開発されています。この API は、バケットという新しいコンセプトを使用して、IndexedDB や localStorage などのさまざまなストレージ API を統合します。バケットに保存されているデータとバケットに関連付けられているメタデータはパーティショニングされます。
  • Clear-Site-Data ヘッダー
    レスポンスに Clear-Site-Data ヘッダーを含めると、サーバーはユーザーのブラウザに保存されているデータを消去するようリクエストできます。キャッシュ、Cookie、DOM ストレージを削除できます。ヘッダーを使用すると、1 つのパーティション内のストレージのみが消去されます。
  • Blob URL ストア
    Blob URL は、元のデータを含むオブジェクトであるblob へのアクセスを提供します。Chrome 137（2025 年 5 月 27 日リリース）以降、Blob URL は通常、取得とナビゲーションのためにパーティショニングされます。つまり、アクセスはストレージキーによってスコープが設定されるようになりました。ストレージキーには、トップレベル サイト、フレーム オリジン、クロスサイト アンセスターが存在するかどうかを示すブール値が含まれます。ただし、Blob URL へのトップレベル ナビゲーションは、フレーム オリジンのみでパーティショニングされます。トップレベル ナビゲーションなどの特定のユースケースでは、Blob URL ストアが最終的にトップレベル サイトだけでなくエージェント クラスタによってキー付けされる可能性があるという議論が進行中です。Blob URL のパーティショニングのこの特定の側面はまだ進化しており、その正確なメカニズムは変更される可能性があります。

Communication API

ストレージ API に加えて、1 つのコンテキストがオリジンの境界を越えて通信できるようにする通信 API もパーティショニングされます。この変更は主に、ブロードキャストまたは同一オリジン ランデブーを使用して他のコンテキストを検出できる API に影響します。

パーティショニングにより、次の通信 API では、サードパーティの iframe が同じオリジンのコンテキストとデータを交換できなくなります。

  • ブロードキャスト チャンネル
    Broadcast Channel API を使用すると、ブラウジング コンテキスト（ウィンドウ、タブ、iframe）と同じオリジンのワーカーとの間で通信できます。
    クロスサイト iframe postMessage() の動作は、それらのコンテキストの関係がすでに明確に定義されているため、変更されることは提案されていません。
  • SharedWorker
    SharedWorker API は、同じオリジンのブラウジング コンテキスト間でアクセスできるワーカーを提供します。
  • ウェブロック
    Web Locks API を使用すると、同じオリジンの 1 つのタブまたはワーカーで実行されているコードが、一部の処理を実行しながら共有リソースのロックを確保できます。

Service Worker API

Service Worker API を使用すると、サイトはバックグラウンドでタスクを実行できます。サイトは、イベントに応答するために新しいワーカー コンテキストを作成するサービス ワーカーを登録します。従来、これらのワーカーは、同じオリジンのコンテキストと通信できました。ただし、Service Worker はナビゲーション リクエストのタイミングを変更できるため、履歴スニッフィングなどのクロスサイト情報漏洩のリスクがあります。

このため、サードパーティ コンテキストから登録された Service Worker はパーティショニングされるようになりました。

Extensions API

拡張機能は、ユーザーがブラウジング エクスペリエンスをカスタマイズできるプログラムです。

拡張機能ページ（chrome-extension:// スキームのページ）は、ウェブ上のサイトに埋め込むことができます。このシナリオでは、拡張機能ページは引き続き最上位パーティションにアクセスできます。拡張機能は他のサイトを埋め込むこともできます。その場合、埋め込まれたサイトは、拡張機能にホスト権限が付与されている限り、トップレベル パーティションにアクセスします。

詳細については、拡張機能のドキュメントをご覧ください。

デモ: ストレージ パーティショニングのテスト

デモサイト: https://storage-partitioning-demo-site-a.glitch.me/

左側に緑色のチェックマーク、右側に赤色の×印が表示されているデモサイト ストレージ パーティショニングありのブラウザ（左）とストレージ パーティショニングなしのブラウザ（右）の出力を示すデモのスクリーンショット。

このデモでは、サイト A とサイト B の 2 つのサイトを使用します。

  • トップレベルのコンテキストでサイト A にアクセスすると、さまざまなストレージ方法を使用してデータが設定されます。
  • サイト B がサイト A のページを埋め込み、その埋め込みが以前に設定されたストレージ オプションの読み取りを試みます。
  • サイト A がサイト B に埋め込まれている場合、ストレージがパーティショニングされているときにサイト A はそのデータにアクセスできないため、読み取りが失敗します。
  • このデモでは、各読み取りの成功または失敗を使用して、データがパーティショニングされているかどうかを示します。

現時点では、--disable-features=ThirdPartyStoragePartitioning コマンドライン スイッチを使用して、Chrome でストレージ パーティショニングをオフにできます。注: このコマンドライン スイッチは開発とテストを目的としており、今後の Chrome バージョンで削除または変更される可能性があります。

他のブラウザでも同様にテストして、パーティショニング ステータスを確認できます。

意見交換とフィードバックの提供