設問と設定
IDプロバイダーが多くの顧客サイトのiframe内に埋め込まれています。サインイン済みのユーザーにはアカウント情報が表示されるべきですが、ブラウザはサードパーティCookieをパーティション化またはブロックする可能性があります。すべての埋め込みを無断追跡チャネルにすることなく、Storage Access APIを使用したフローを設計してください。
iframeは独自のファーストパーティページに遷移可能であり、トップレベルサイトがiframeの権限を制御し、ユーザーはプロンプトを拒否する可能性があると想定します。回答では、同意、CSRF、フォールバック、およびログアウトを網羅する必要があります。
面接官がテストするポイント
- ストレージアクセスがユニバーサルなCookie切り替えスイッチではなく、権限によって制限され、フレームスコープ（frame-scoped）であることを理解しているか。
- アクセスを要求する前に、ユーザーアクティベーションと製品上の明示的な理由を必須としているか。
- パーティション化された初期化状態と、パーティション化されていないセッション状態を分離しているか。
- 拒否された場合に、サインアウト状態またはリダイレクトベースの機能的なパスが残されているか。
回答前の確認質問
- ウィジェットはクロスサイトのセッション継続性を必要としていますか、それともリダイレクトによって認可コードを返せば十分ですか？リダイレクトを使用すれば、埋め込みCookieアクセスの要求を回避できる場合があります。
- ユーザーはファーストパーティとしてIDプロバイダーにアクセスし、そのCookieを設定したことがありますか？一部のブラウザでは、アクセスを許可する前にその関係性を必要とします。
- どのトップレベルオリジンがフレームを埋め込む可能性がありますか？これによって
Permissions-Policyの許可リストが決まります。 - 同意前にどのようなデータが表示されますか？アクセス前のビューでアカウントのID情報が漏洩してはなりません。
30秒の回答フレームワーク
「私はStorage Access APIを、Cookieのフォールバック用トグルとしてではなく、ユーザーを介した機能として扱います。iframeはパーティション化された状態または不透明な状態から開始し、メリットを明確に説明するクリックの後にのみアクセスを要求し、返されたPromiseを検証します。トップレベルサイトは限定的なPermissions-Policy許可リストを送信します。拒否された場合は、ファーストパーティリダイレクトまたはサインアウト状態の体験を使用します。状態を変更するすべてのリクエストには引き続きCSRF保護を適用し、ウィジェットはセッションを破棄して同じニュートラルな状態に戻ることができます。」
ステップごとの詳細解説
1. 状態と脅威モデルの分離
アクセス前、iframeはパーティション化されたストレージを持つか、Cookieを持たない場合があります。その状態からユーザーのID情報を推測してはなりません。requestStorageAccess()が成功した後、埋め込まれたドキュメントはブラウザのポリシーに従って、パーティション化されていないファーストパーティCookieにアクセスできます。
この機能のスコープは、ドキュメントおよび埋め込みコンテキストに限定されます。これはトップレベルサイトが信頼されていることの証明ではなく、オリジンチェック、CSRF防御、同意記録、およびログアウトセマンティクスの代わりになるものでもありません。
2. ユーザーの意図によるリクエストの制御
ニュートラルなサインアウト状態のウィジェットを描画します。「アカウント詳細を表示するにはサインイン」などのボタンによってユーザーアクティベーションを作成します。そのハンドラー内でAPIを呼び出し、拒否を想定される分岐として処理します。ページ読み込み時にアクセスを要求したり、隠しフレームを使用してアクティベーションを偽装したりしてはなりません。
アプリケーションは、どのデータが利用可能になるかを説明し、ブラウザポリシーで許可されている範囲でのみ決定を記憶する必要があります。リクエストは、ブラウザがサードパーティCookieをブロックしている、ユーザーがファーストパーティとしてサイトと対話していない、フレームにポリシー権限がない、またはコンテキストが対象外であるなどの理由で拒否される可能性があります。
3. 埋め込み境界の設定
トップレベルのレスポンスがポリシーを管理します。ウィジェットを埋め込むルートでのみ、IDオリジンのみを許可します。
Permissions-Policy: storage-access=(self "https://id.example")iframeは、想定されるオリジンとsandbox設定で提供されなければなりません。サンドボックス化されたフレームには適切なsame-origin機能が必要であり、オリジンの不一致はフェイルクローズ（安全側に倒して拒否）する必要があります。ポリシーは許可リストとして扱い、すべてのサードパーティにアクセスを許可する手段として扱ってはなりません。
4. ファーストパーティフローと埋め込みフローの確立
ブラウザがファーストパーティでの対話を必要とする場合、ウィジェットはIDオリジン上のファーストパーティページを開きます。ユーザーはそこでサインインし、IDプロバイダーはそのファーストパーティCookieを設定し、短時間有効でオリジンにバインドされた結果が埋め込み側に返されます。この結果は、URL内の再利用可能なベアラートークンであってはなりません。
iframeに戻ったら、ユーザー操作後にストレージアクセスを要求し、IDオリジン経由でセッションを読み取ります。サーバーは引き続きトップレベルオリジン、セッション状態、およびCSRFトークンを検証します。アクセスの許可が成功しても、アカウントの認可処理がバイパスされるわけではありません。
5. 拒否、ログアウト、および計測の設計
アクセスが拒否された場合でも、ウィジェットの有用性を維持します。サインインリンクの表示、リダイレクトして復帰するフローの使用、またはファーストパーティのアカウントページの提示などを行います。プロンプトをループさせてはなりません。ログアウトによってIDセッションがクリアされ、iframeがニュートラルな状態にリセットされます。また、キャッシュされたアカウントビューも無効化する必要があります。
許可の成功、利用可能な場合の拒否理由、リダイレクトの完了、およびアカウントビューのエラーをブラウザおよび埋め込みオリジンごとに計測します。Cookieの値やアカウントデータをログに記録してはなりません。製品は、リダイレクトフローを失うことなく、後からAPIパスを削除できるように設計する必要があります。
高品質な回答例
私はまず、サインイン操作要素のみを描画する匿名iframeから始めます。ユーザーのクリック後、ストレージアクセスを要求し、明示的に拒否を処理します。埋め込み元のページは、IDオリジンに対する限定的なPermissions-Policy許可リストを送信します。ブラウザがファーストパーティでの対話を必要とする場合、IDサイトへリダイレクトしてそこでセッションを確立し、URLにベアラートークンを含めることなくオリジンにバインドされた結果を返します。
アクセス許可後、iframeはファーストパーティセッションを読み取りますが、オリジンチェック、CSRF保護、認可、およびログアウトは引き続き適用されます。アクセスが拒否された場合、製品はリダイレクトログインまたはサインアウトビューを使用し、プロンプトをループさせることは決してありません。フォールバックの機能を維持しながら、許可、拒否、リダイレクト完了、およびエラーをブラウザとオリジンごとに計測します。
よくある間違い
- 間違い: ページ読み込み時にAPIを呼び出す → 失敗する理由: ブラウザはユーザーの意図を必要としており、ユーザーは突然のプロンプトを理解できない → 修正方法: 説明を伴うアクティベーションの後にのみ要求する。
- 間違い: 成功をグローバルなCookie権限として扱う → 失敗する理由: アクセスはスコープが制限されており、ポリシーやブラウザに依存する → 修正方法: 埋め込みコンテキストごとにPromiseをチェックする。
- 間違い:
Permissions-Policyですべてのオリジンを許可する → 失敗する理由: トラッキングおよびデータアクセスの攻撃面が拡大する → 修正方法: 特定のルートでIDオリジンのみを許可リストに登録する。 - 間違い: リダイレクトURLにセッショントークンを含める → 失敗する理由: 履歴、ログ、Refererを通じてURLが漏洩する → 修正方法: 短時間のみ有効で使い捨ての、オリジンにバインドされた結果を使用する。
- 間違い: 拒否後にプロンプトを繰り返す → 失敗する理由: ユーザーにとって不快なループが発生し、それでも権限を強制することはできない → 修正方法: リダイレクトまたはサインアウト時のフォールバックに切り替える。
フォローアップ質問と回答
パーティション化されたCookieはStorage Access APIを代替できますか？
埋め込み固有の初期ブートストラップセッションをサポートすることはできますが、パーティション化されていないファーストパーティセッションと同じクロスサイトの継続性は提供できません。分離が許容される場合はパーティション化された状態を選択し、継続性が重要でアクセス要求が望ましくない場合はリダイレクトログインを使用してください。
iframeがサンドボックス化されている場合はどうなりますか？
サンドボックスが、フローに必要なオリジンと機能を保持していることを確認します。オリジンが不透明（opaque）になる場合やAPIがブロックされる場合は、フェイルクローズしてファーストパーティリダイレクトを使用します。1つの埋め込みを動作させるためだけに、サンドボックス全体を弱めるようなことはしないでください。
ストレージアクセスが許可されればCSRFリスクはなくなりますか？
いいえ。アクセス後、iframeはCookieを送信できるようになるため、状態を変更するエンドポイントには引き続きCSRF防御、オリジン検証、該当する場合はSameSite Cookie設定、および認可が必要です。ストレージ権限は到達可能性を変更するだけであり、リクエストの意図を保証するものではありません。