まず異なる二つの課題を分ける

HTTP Cookieは、ログイン状態や設定などをリクエスト間で維持する仕組みです。ウィジェット、決済機能、地図などを別のサイトに埋め込むと、「どのリクエストでCookieを送るか」と「埋め込み先をまたいで状態を共有するか」という別々の問いが生じます。

SameSiteは同一サイト・クロスサイトというリクエストの文脈に応じて送信を制限します。CHIPS（Cookies Having Independent Partitioned State）は、埋め込みサービスがトップレベルサイトごとに分かれたCookie保存領域を選択できる仕組みです。前者は送信ポリシー、後者は保存状態の分割です。同じ機能の別名ではなく、併用もできます。

SameSiteのリクエスト文脈ルールとトップレベルサイト別CHIPS保存領域の概念比較図

SameSiteで変わること

IETFのHTTP作業グループによるRFC6265bis草案はStrict、Lax、Noneの動作を説明しています。Strictはクロスサイトリクエストでより送信を制限し、Laxは一部のトップレベル遷移を許容します。Noneはクロスサイト利用を示す値で、Secureと組み合わせる必要があります。実際の結果はリクエストの種類とブラウザー実装にも左右されるため、製品が使う経路を試験してください。

SameSiteはクロスサイトリクエストフォージェリ（CSRF）への多層防御であり、完全なセキュリティ境界ではありません。状態を変更する操作の権限確認や専用のCSRF対策を置き換えません。サイト境界、遷移、リダイレクト、フォーム送信の違いを無視し、クロスサイトの要求はすべて遮断されると仮定すると抜けが生じます。

CHIPSが埋め込み状態を分ける仕組み

Google Privacy Sandboxの資料は、Partitioned属性によるオプトインの分割保存としてCHIPSを説明します。埋め込みサービスのCookieはトップレベルサイトに関連づいたパーティションに保存されます。同じコメントウィジェットでも、異なる媒体サイトに埋め込まれた場合、共通Cookieを自動共有せず各サイトの文脈で別の状態を保てます。

資料の例は Set-Cookie: __Host-example=123; Secure; Path=/; SameSite=None; Partitioned です。SameSite=Noneはクロスサイト埋め込み要求での利用を可能にし、Partitionedはトップレベルサイトごとに保存を分け、Secureは安全な接続を要求します。属性やブラウザー条件が欠けると、期待どおり保存・送信されないことがあります。応答ヘッダーとブラウザー内のCookie保存状況の両方を確認しましょう。

専門家の視点：プライバシーやCSRFの万能策ではない

CHIPSは、埋め込みサービスが全サイトで一つのCookieを共有せず、サイト別のセッションや設定を維持したい場合に役立ちます。変えるのは保存境界です。Cookie値を自動的に匿名化したり、アプリケーションデータを消したり、認可の欠陥を修正したりするものではありません。ファーストパーティ内の行動やサーバーログなど、ほかのデータの扱いも別途検討します。

Partitioned属性だけでCSRF対策が完成するわけでもありません。SameSiteとCHIPSは異なる課題に対応し、認証・認可・要求検証・安全な状態変更設計を置き換えません。実際のパーティションキーとサイト境界が製品の意図に合うか、サブドメインや埋め込みの条件も含めて確かめます。

実装前の確認項目

状態をトップレベルサイト間で共有する必要が本当にあるかを決めます。サイトごとに分けるべき埋め込み機能なら、CHIPSが用途に合うか検討し、サーバーが意図したPartitioned、Secure、SameSite属性を返すことを確認します。ログイン、リダイレクト、新しいタブ、クロスサイトフォーム、iframeなど実際の経路を対象ブラウザーで試験します。

ブラウザーの対応状況や既定ポリシーは変わります。引用したIETF資料は2025年12月のRFC6265bis草案22版で、公開RFCではありません。Datatrackerには2026年6月4日の失効日が示されています。現行の規範文書として扱わず、実装時にDatatrackerの状態と対象ブラウザーの最新資料を確認してください。GoogleのCHIPS資料も実際の対象環境で挙動を検証します。

出典