1. 質問とコンテキスト
プロダクトで請求書、ファイル、または1回限りのアクションを共有する必要があります。リンク自体がアクセス権限（ケイパビリティ）を保持しているため、サーバーは最初にログイン済みのアカウントを特定する必要がありません。面接の焦点は、このモデルがどのような場合に妥当であるか、およびリンクがコピー、ログ記録、または転送される事態にどう対処するかです。
2. 面接官が評価していること
- ケイパビリティURL、ログインセッション、OAuthベアラートークンの信頼モデルを区別できているか。
- 脅威モデルに、ログ、履歴、アナリティクス、リファラー、スクリーンショットによるURL漏洩が含まれているか。
- 短い有効期限、最小権限、使い捨て（1回限り）、またはオーディエンスバインディングを設計しているか。
- グローバルキーのローテーションだけでなく、リンクごとの失効、一括失効、監査可能性をサポートしているか。
W3CのケイパビリティURLガイダンスでは、ケイパビリティURLが漏洩した場合に付与されたアクセス権を取り消せ（失効でき）なければならないとされています。OWASPはパスワード、APIキー、セキュリティトークンをURLに含めることを明示的に推奨していないため、ケイパビリティURLには明確なリスク境界と補償コントロールが必要です。
3. 回答前の明確化のための質問
- リソースは公開情報、低機密度、それとも個人情報、財務情報、規制対象データですか？
- 訪問者はサインインが必要ですか？また、リンクは組織の境界を越えますか？
- アクセスは1回限りのダウンロード、短い期間、それとも長期的なコラボレーションですか？
- 漏洩後、失効させる必要があるのは1つのリンク、1人のユーザー、それともリソース全体ですか？
4. 30秒の回答フレームワーク
適合性、トークン、漏洩、失効、代替案を使用します。
私はケイパビリティURLを、所持によるアクセスが許容される低頻度かつ監査可能なアクセスにのみ使用し、対象を単一のリソースと短い期間に限定します。トークンは高エントロピーで予測不可能でなければなりません。サーバーにはハッシュのみを保存し、作成、使用、失効を記録します。Referrer-Policy: no-referrerを設定し、ログやサードパーティのアナリティクスから除外します。機密性の高いリソースには認証付きの認可を使用し、ケイパビリティURLは1回限りの招待やダウンロード資格情報に限定すべきです。
5. ステップバイステップの詳細解説
ステップ1: 適切な信頼モデルの選択
ケイパビリティURLは、所持していることで権限が付与されることを意味し、アカウントの身元を証明するものではありません。低機密度の共有、1回限りのダウンロード、または登録不要の招待に適しています。きめ細かなメンバーシップ管理、長期的な監査要件、または強力な身元保証には適していません。OAuthベアラートークンの場合はAuthorizationヘッダーを優先してください。RFC 6750ではURIクエリパラメータも利用可能と記載されていますが、リスクの高い転送方法とされています。
ステップ2: ケイパビリティの最小化
トークンをリソース、アクション、オーディエンスにバインドします。短い有効期限、使い捨てマーカー、レート制限を追加します。転送可能なワークフローの場合は、利用（引き換え）前に受信者の確認またはログインを要求します。暗号学的に安全な乱数生成器でトークンを生成し、ハッシュのみを保存することで、データベースが漏洩しても即座に使用可能な資格情報にならないようにします。
ステップ3: URL漏洩の制御
OWASPが指摘しているように、URLはサーバーログ、ブラウザの履歴、プロキシの記録に残ります。トークンを受信した後、ランディングページは安全なリクエストを介してトークンを短命なセッションと交換し、アドレスバーからトークンを削除する必要があります。厳格なリファラーポリシーを使用し、トークンを受け取る可能性のあるサードパーティリソースを避けます。メール、スクリーンショット、チャットツールでもリンクが公開される可能性があるため、長期間有効な高権限のアクセス権をリンクに含めてはなりません。
ステップ4: 正確な失効と監査の実装
トークンごとに、作成者、リソース、アクション、有効期限、最終使用日時、失効日時を記録します。利用またはダウンロードのたびに失効状態を確認します。リンクごとの失効がグローバルキーのローテーションに依存してはなりません。漏洩や悪用を調査できるように、成功、失敗、重複、失効済みの使用を理由とともに監査します。
6. 高品質な回答例
私はまず機密度と有効期間を分類します。公開ハンドブックにケイパビリティURLは不要です。外部レビュー用の低機密度の請求書には使用できますが、機密性の高い財務レポートにはログインと組織の権限が必要とされるべきです。
>
許容されるケースでは、少なくとも128ビットのランダム性を生成し、トークンを1つのリソース、1つのアクション、24時間の有効枠にバインドします。データベースにはトークンのハッシュ、ステータス、監査フィールドのみを保存します。利用が成功すると即座に使用済みとしてマークされ、ダウンロードエンドポイントは毎回有効期限と失効を確認します。レスポンスにはReferrer-Policy: no-referrerを設定します。利用後、トークンはアドレスバーから削除され、ページはリファラーを受け取る可能性のあるサードパーティリソースを回避します。
>
ユーザーは単一のリンクを失効でき、管理者はリソース単位でリンクを失効できます。失効や重複した使用は監査されます。プロダクトで後にコラボレーションが必要になった場合は、ケイパビリティURLを永続的なベアラートークンに拡張するのではなく、認証付き認可とメンバーシップ権限に移行します。これにより、共有の利便性を保ちながら、漏洩の影響を単一リソースと限られた時間に抑えることができます。
7. よくある失敗パターン
- ログ、履歴、転送を無視して、長いリンクをセキュリティ対策として扱う。
- 予測可能なリソースIDや自動インクリメントされるトークンを使用する。
- 有効期間が長く高権限のベアラートークンをクエリパラメータに配置する。
- グローバルキーのローテーションのみをサポートし、リンクごとの失効に対応しない。
- 利用後にアドレスバーにトークンを残したまま、サードパーティの画像やアナリティクスを読み込む。
8. フォローアップ質問と回答
フォローアップ1: なぜトークンのハッシュのみを保存するのですか？
トークンは保持者の資格情報です。データベースの読み取りアクセスが漏洩した場合、平文のトークンは即座に利用可能になってしまいます。ハッシュ化することで、サーバーは静的ストレージを資格情報のダンプにすることなく、送信された値を照合できます。
フォローアップ2: 単一使用（使い捨て）にするとリフレッシュが失敗しませんか？
1回限りのトークンを使用して短命なセッションと交換します。リフレッシュには元のリンクを再度利用するのではなく、そのセッションを使用します。利用は成功したもののレスポンスが失われた場合は、長期的な権限を再開することなく、制約された冪等な利用結果を提供します。
フォローアップ3: ケイパビリティURLを完全に放棄すべきなのはどのような場合ですか？
リソースの機密性が非常に高い場合、メンバーシップを継続的に管理する必要がある場合、呼び出し元の身元を証明する必要がある場合、または組織が一元的な失効と監査を必要とする場合は、認証付きの認可とサーバー側の権限を使用してください。