質問とシナリオ
このウィジェットは support.example から配信され、shop-a.example や shop-b.example などのトップレベルサイトによって埋め込まれます。shop-a.example 配下の製品、チェックアウト、ヘルプページ間ではセッションを保持する必要がありますが、shop-b.example には分離された状態が渡される必要があります。設計では、制限されたサードパーティ Cookie、古いブラウザ、ログアウト、オペレーターへの引き継ぎ、および複数タブを考慮しなければなりません。
面接官がテストしていること
- 候補者が、CHIPS が Cookie をトップレベルサイトと埋め込みオリジンの両方でキー指定することを理解しているか？
- サイトごとの永続的な状態と、ユーザーの許可を必要とする非パーティション化サードパーティ状態を区別できるか？
- Cookie 設計、サーバーセッション、CSRF、リプレイ保護、およびログアウトを1つのデータフローに統合できるか？
- 機能検出、レガシーフォールバック、キャッシュキー、および可観測性をカバーしているか？
最初に確認すべき明確化のための質問
HTTPS であること、ウィジェットがトップレベルサイトをまたいで同一人物を特定する必要があるか、サブドメイン間でセッションを共有するか、およびトップレベルのログインページが許容されるかを確認します。データの機密性、セッションの有効期間、サーバープッシュ、および対象ブラウザを明確にします。ビジネス上本当にクロスサイトのアイデンティティが必要な場合、CHIPS 単体はその仕組みではないため、明示的なログインまたは認可を使用します。
30秒の回答フレームワーク
セッションは1つのトップレベルサイトに属するものとして定義します。ウィジェットは Partitioned を使用してセキュアな Cookie を設定し、サーバーはトップレベルサイトとウィジェットセッションを使用して状態を解決します。1つのサイトのサブドメインはそのパーティションを共有しますが、別のサイトは異なるパーティションを取得します。この Cookie はクロスサイトのアイデンティティクレデンシャルではありません。クロスサイトログインにはトップレベルの認可フローを使用します。CHIPS が利用できない場合は、永続状態なしで実行するか、ユーザーに明示的な認可を求めます。ログアウト、CSRF、キャッシュ分離、および複数タブの動作をエンドツーエンドで検証します。
ステップバイステップの詳細解説
- 信頼境界を定義する。 埋め込みサイトを、
Origin文字列から派生した認可決定としてではなく、パーティションコンテキストとして扱います。許可リストを保持し、メッセージオリジン、テナント、およびセッション状態を検証します。 - パーティション化 Cookie を設定する。
Secure、適切なSameSiteの値、およびPartitionedを使用します。現在のホストにバインドする場合は__Hostプレフィックスを優先します。論理的な Cookie キーには埋め込みオリジンとトップレベルサイトが含まれるため、同じウィジェットが2つのトップレベルサイト間で1つの Cookie を読み取ることはできません。 - サーバーセッションを設計する。 Cookie にはランダムな不透明識別子（opaque identifier）のみを保存します。サーバーセッションには、テナント、トップレベルサイト、作成日時、有効期限、および失効バージョンを記録します。ブラウザのパーティショニングのみに依存するのではなく、リクエストごとにバインディングを再検証します。
- サブドメインとキャッシュを処理する。 サブドメインは1つのトップレベルパーティションを再利用できますが、HTML、スクリプト、および API のキャッシュキーにはテナントまたはセッションのバリエーションを含める必要があります。パーソナライズされたレスポンスにはプライベートキャッシュまたは明示的な
Varyポリシーを使用し、CDN があるサイトの状態を別のサイトに配信しないようにします。 - ログインと認可を設計する。 同一人物を認識する必要がある場合は、トップレベルのログインページを開き、短期間有効なワンタイム認可コードを返します。有効期間の長いトークンを URL、
postMessage、または非パーティション化 Cookie に配置してはなりません。 - フォールバックと可観測性を提供する。 サポートがない場合はセッションなしモードで実行するか明示的な認可を要求します。グローバルなサードパーティ Cookie を暗黙的に復元してはなりません。Cookie の値やトークンをログに記録することなく、パーティション Cookie のヒット率、認可の成功、およびセッションの作成や失効の理由を追跡します。
高品質な回答例
1つのトップレベルサイト内でウィジェットの状態を保持する境界として CHIPS を使用します。support.example は Secure、SameSite=None、および Partitioned を持つ Cookie を設定し、不透明なセッション識別子のみを保存します。サーバーセッションはテナント、トップレベルサイト、有効期限、および失効バージョンをバインドします。shop-a.example 配下のサブドメインは1つのパーティションを再利用しますが、shop-b.example は当然別の状態を受け取ります。
クロスサイトのアイデンティティはその Cookie に依存しません。ウィジェットはログイン用のトップレベルページを開き、ユーザーのアクション後にワンタイム認可コードを取得し、検証されたメッセージチャネルを通じて現在のパーティション内の短期間セッションと交換します。古いブラウザやポリシーがパーティション化 Cookie をブロックしている場合、ウィジェットはグローバルなサードパーティ Cookie にフォールバックするのではなく、セッションなしの体験または明示的な認可を提供します。2つのトップレベルサイト、サブドメイン、ログアウト、有効期限、同時タブ、キャッシング、CSRF、偽造メッセージ、およびプライバシー設定をテストします。主なリファレンスは、MDN の CHIPS および Storage Access API ドキュメント、ならびに Privacy Sandbox の CHIPS の説明です。
よくある間違い
PartitionedCookie をクロスサイトのシングルサインオン（SSO）クレデンシャルとして扱い、分離を無効にしてしまう。- テナントバインディング、失効、CSRF、およびリプレイを無視して、
Originのみから認可を行う。 - CHIPS が利用できない場合に非パーティション化サードパーティ Cookie を暗黙的に使用し、漏洩やブロックを引き起こす。
- CDN、Service Worker、またはプロキシのキャッシュバリエーションを省略し、あるサイトのパーソナライズされたレスポンスを別のサイトに配信してしまう。
- 有効期間の長いトークンを URL、
postMessage、またはフロントエンドで読み取り可能な Cookie に配置する。
フォローアップ質問と回答
CHIPS と Storage Access API はどのように使い分けますか？
トップレベルサイトごとに独立した埋め込み状態には CHIPS を使用します。明示的なサインインなど、非パーティション化サードパーティ状態に対する正当な必要性があり、ユーザーが許可を付与できる場合は Storage Access API を使用します。これらはプライバシー境界が異なるため、一方がもう一方の暗黙の代替手段になることはありません。
2つのトップレベルサイトがセッションを共有できないことをどのように証明しますか？
同一ブラウザで両方のサイトにウィジェットを埋め込み、セッション識別子、サーバーのテナントバインディング、およびキャッシュヒットを記録します。一方のサイトの Cookie のクリア、ログアウト、新しいタブのオープン、およびサブドメインの切り替えを行っても、もう一方のサイトの状態が変化してはなりません。
プロダクトがサイト間で同一人物を認識することを強く求めた場合はどうしますか？
要件を明示的なアイデンティティ認可（トップレベルログイン、短期間のワンタイムコード、サーバー間交換、および失効可能なセッション）にアップグレードします。隠れたクロスサイトトラッキングチャネルを作成するのではなく、同意と失敗を記録します。