認証情報をどこに保存するか - ブラウザの脅威モデル | 仕組み解説

保存場所だけで安全性は決まらない

memory、sessionStorage、localStorage、CookieをJavaScript読取、自動送信、消える時期、XSSとCSRFの観点で比較し、architectureに応じて選ぶ表

保存期間などの基本比較は、canonical記事のlocalStorageとCookieの違いで確認できます。この記事では、認証情報の置き場所を決めるときの脅威モデルに絞ります。

「どこが一番安全か」ではなく、攻撃時に何を盗まれ、何を操作され、どのくらい被害が続くかを比較します。

見る軸は次の5つです。

保存場所	XSSで値を読まれる可能性	自動送信	主な注意
メモリ	実行中はあり	なし	永続化しないが、実行中のXSSは操作できる
sessionStorage	あり	なし	タブ終了まで残り、XSSから読める
localStorage	あり	なし	長期間残り、XSSから読める
HttpOnly Cookie	値の直接読取は不可	あり	XSSによる操作とCSRFは別対策が必要

認証情報を置く場所として見ると、判断は次のようになります。

保存場所	access token	refresh token	セッションID
メモリ	短命なら候補	リロードで失われる	通常は不要
sessionStorage	XSSとタブ寿命を考慮	長期tokenには不向き	通常は使わない
localStorage	長期保存を避ける	長期保存を避ける	通常は使わない
HttpOnly Cookie	自動送信とCSRFを含め設計	認証基盤の推奨次第	代表的な選択
サーバー側ストア	BFF等で管理可能	BFF等で管理可能	IDに対応する状態を保存

BFF構成では、ブラウザにHttpOnly CookieのセッションIDを持たせ、access tokenやrefresh tokenをサーバー側で管理できます。これは有力な選択肢ですが、サーバー側の状態管理、CookieのCSRF対策、セッション固定・失効対策が必要です。

初心者のうちは、リロードしてログイン情報が消えると「不便だからlocalStorageに入れよう」と考えがちです。

しかし、認証情報は便利に残せばよいものではありません。長く残るほど、盗まれたときの被害も長く残ります。

たとえば、メモリ上に短命access tokenだけを置き、リロード後は認証フローで復元する設計があります。永続化による露出時間は減りますが、実行中のXSSから安全になるわけではありません。

ポイント: 認証設計では「消えないから便利」だけで判断しません。「盗まれたら何ができるか」「どれくらいの期間使えるか」で判断します。

認証情報の保存場所は、XSSだけで決めません。

認証情報では、保存場所の選択がセキュリティ設計そのものになります。