sessionStorageは、localStorageとAPIが完全に同じでありながら、データの寿命が「ブラウジングコンテキスト」つまりタブやウィンドウを開いている間だけに限定されるストレージです。2011年12月にW3CがWeb Storage勧告として localStorage とともに標準化し、現在もWHATWG HTML Living Standard内で仕様が維持されています。タブを閉じれば自動的に消えるという性質は、永続化したくない一時データを扱う場面で非常に便利で、認証フローの一時状態やマルチステップフォームの途中経過保持などに採用されています。
この記事の目次
- localStorageと同じAPI・違う寿命
- セッション寿命の細かい挙動
- 現場で活躍するシーン
- 他のストレージと比較した選択基準
- まとめ
localStorageと同じAPI・違う寿命
sessionStorageの呼び出し方は sessionStorage.setItem('k', 'v') のように、localStorageと同じインターフェースを持ちます。getItem removeItem clear key length、そしてプロパティ風アクセスも完全に共通です。違いはただ一点、寿命がそのタブやウィンドウが閉じられるまでに限定される点だけです。これにより「ログイン後の二要素認証コード入力中だけ保持しておきたい一時トークン」「申し込みフォームの3ページ目までの入力内容」といった一過性のデータを安全に扱えます。
重要な特徴として、sessionStorageは「タブごと」に独立しています。同じURLを別タブで開いてもそれぞれ別のsessionStorageが割り当てられ、相互に内容を見ることはできません。リンクを target="_blank" で開いたり window.open で生成したりした子ウィンドウは親のsessionStorageを引き継ぐ「複製」が行われますが、その後は独立して動きます。ブラウザの「タブの復元」機能でセッションが復活した場合のみ内容が残る点も覚えておくと役立ちます。
セッション寿命の細かい挙動
sessionStorageは「タブ単位＋同一オリジン単位」でスコープが決まります。同じタブ内でページを移動しても同じオリジンであれば内容は保持され、リロードしても消えません。別オリジンへ移動すれば当然そのオリジンのsessionStorageに切り替わります。ブラウザによってはタブを閉じても直後の「閉じたタブを開き直す」操作で復活する場合があり、厳密に「閉じた瞬間に消える」を保証したい場合は beforeunload イベントで明示的に clear する設計が安心です。
ブラウザのプライベートモード（シークレットモード）でも普通に動きますが、プライベートウィンドウを閉じた時点で確実に消去されます。複数のプライベートウィンドウ間でもsessionStorageは共有されません。タブの「グループ化」「ピン留め」「スリープタブ」といった新機能の影響もブラウザによって挙動が微妙に異なるため、本格的なステート管理には頼らず、あくまで「タブを閉じたら消えてよいデータ」だけを置くのが安全な使い方です。
現場で活躍するシーン
OAuth 2.0やOpenID Connectのコールバックフローで使う state nonce code_verifier といった一回限りのパラメータは、まさにsessionStorageの典型的な使い所です。認証サーバーへリダイレクトする前に保存し、戻ってきた直後に検証して即削除、というライフサイクルで、もしタブを閉じてしまえば自動的に消えるためセキュリティ的にも安心です。localStorageに長期で残してしまうと、後から別の攻撃でその値を悪用される余地が生まれるため、明確にsessionStorageを選ぶ場面です。
もう一つの典型は、ステップ数の多い申し込みフォームや決済画面のカート情報の保持です。ユーザーがリロードしても入力内容を維持したい一方で、別タブの同じ申し込みフォームには影響を与えたくない、という両立に役立ちます。SPAのページ遷移時のスクロール位置の記憶や、管理画面で適用中のフィルタ条件をリロード後も維持する用途にも好相性です。「一時的だがリロード耐性は欲しい」というギャップを綺麗に埋めるのがsessionStorageの強みです。
他のストレージと比較した選択基準
sessionStorageが向かないのは、まずタブ間で情報を共有したい場合です。タブごとに独立するため、別タブから同じ値を参照することはできません。タブ間連携にはlocalStorageかBroadcast Channel APIを使います。また5MB程度の容量制限と文字列のみの保存というlocalStorage同様の制約も引き継いでいるため、ファイル本体や画像Blobの保存にはIndexedDBを選ぶべきです。サーバー側で参照したい一時状態はそもそもブラウザでなくCookie＋サーバーセッションで管理する設計が望ましいでしょう。
それでもsessionStorageは「永続化したくないが少しの間だけ保持したい」「タブごとに独立させたい」という二つの要件を、追加ライブラリ無しで完璧に満たす唯一のAPIです。XSSのリスクはlocalStorageと同じため機微な値の保存には注意が必要ですが、寿命がタブ閉じまでに限定される分、被害範囲も小さく抑えられます。適切な場面で選択すれば、フロントエンドの状態管理を非常に簡潔に書ける道具で、PoCから本番アプリまで幅広く現役で使われ続けています。
まとめ
sessionStorageは、localStorageの双子でありながら寿命が「タブを開いている間」に限定された一時的なキー値ストアです。OAuth state・多段階フォーム・カート一時保持といった短命なデータの管理にぴったり合い、APIの簡単さと自動消去の安心感を両立しています。永続性が要らない場面では真っ先に検討したい選択肢です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント