ブラウザでのJWT保存場所

ブラウザでJWTを保存する場所は、アプリケーションのセキュリティ態勢に大きく影響します。各保存メカニズムには異なる脆弱性プロファイルがあり、適切な選択は脅威モデルとアプリケーションアーキテクチャに依存します。

localStorage:

localStorage.setItem('access_token', jwt);
// タブ間およびブラウザ再起動後も永続化

localStorageは同じオリジンで実行されるすべてのJavaScriptからアクセス可能であり、クロスサイトスクリプティング（XSS）攻撃に脆弱です。攻撃者が悪意のあるJavaScriptを注入できた場合（脆弱な依存関係、サニタイズされていない入力、またはサードパーティスクリプトを通じて）、localStorage.getItem('access_token')でトークンを読み取り、外部に送信できます。localStorageの便利さ（永続性、簡単なAPI）には実際のセキュリティコストが伴います。低感度のアプリケーション、または堅牢なXSS防止と組み合わせる場合にのみ適しています。

sessionStorage:

localStorageと類似していますが、単一のブラウザタブにスコープされ、タブを閉じるとクリアされます。localStorageと同じXSS脆弱性がありますが、永続化ウィンドウが制限されます。新しいタブを開くと再認証が必要になるため、ほとんどの認証シナリオには推奨されません。

HttpOnly Cookie:

Set-Cookie: access_token=eyJhbGc...; HttpOnly; Secure; SameSite=Strict; Path=/

HttpOnly CookieはJavaScriptからアクセスできないため、XSSベースのトークン窃取を完全に排除します。ブラウザは一致するドメインへのすべてのリクエストに自動的にCookieを送信します。ただし、Cookieはクロスサイトリクエストフォージェリ（CSRF）リスクを導入するため、SameSite=StrictまたはSameSite=Lax属性、CSRFトークン、またはカスタムヘッダー要件で軽減する必要があります。HttpOnly Cookieはセキュリティに敏感なアプリケーションに推奨される保存メカニズムです。

インメモリ保存:

トークンをJavaScript変数（例: Reactコンテキストやクロージャ内）に保存すると、ページリフレッシュ後は維持されず、アプリケーションのJavaScriptのみがアクセス可能です。XSSからの最強の分離を提供しますが、永続性は最低です。HttpOnly Cookieに保存されたリフレッシュトークンと組み合わせるとうまく機能します。ページロード時にアプリはリフレッシュCookieを使用して新しいアクセストークンを取得し、メモリ内に保持します。

推奨パターン:

リフレッシュトークンはHttpOnly、Secure、SameSite=Strict CookieにMemoに保存します。アクセストークンはメモリ内（JavaScript変数）に保存します。ページロード時にリフレッシュCookieを使用してサイレントに新しいアクセストークンを取得します。このアプローチは両方のトークンのXSS露出を排除し、APIを認可するアクセストークンがCookieに入らないためCSRFリスクを制限します。