徹底解説：Webストレージ（localStorage／sessionStorage）の仕組み・制限・実践的対策
エバープレイ編集部概要：Webストレージとは何か
Webストレージ（Web Storage API）は、ブラウザ上でキーと値のペアを永続的またはセッション単位で保存するための標準APIです。代表的なインターフェースに localStorage と sessionStorage があり、いずれも同一オリジン（スキーム、ホスト、ポートが同じ）のコンテキスト間でデータを共有できます。従来のクッキーに比べて容量が大きく、HTTPリクエストに自動送信されないため、クッキーよりも用途が限定されるクライアントサイドのデータ保存に適しています。
基本的な違い：localStorage と sessionStorage
localStorage：ブラウザを閉じてもデータが残る永続ストレージです。同一オリジン内の全タブやウィンドウで共有されます（例：同じドメインの別タブから読み書き可能）。
sessionStorage：タブ／ウィンドウ単位のストレージで、そのタブ（またはウィンドウ）を閉じるとデータは破棄されます。同一オリジンでも別タブ間で共有されません。
主なAPIと使い方
基本的なメソッドは両方とも同じインターフェースを持ちます：
setItem(key, value)：キーに対して文字列として保存。getItem(key)：キーに対応する文字列を取得。存在しない場合はnull。removeItem(key)：指定キーを削除。clear()：全エントリを削除。key(index)およびlength：インデックス指定のキー取得や総エントリ数の確認。
重要な点は、保存できる値は常に文字列であることです。オブジェクトや配列を保存したい場合は、JSON.stringify() と JSON.parse() を使ってシリアライズ／デシリアライズします。
容量とブラウザ依存の挙動
Webストレージの容量はブラウザやバージョンに依存し、具体的な上限は一概には言えません。代表的な目安は次の通りです（変更される可能性あり）：
Chrome / Edge：オリジンごとに約5〜10MB（実装やプラットフォームにより差あり）。
Firefox：オリジンごとに約10MB（以前は5MBだったが変動する）。
Safari（デスクトップ/モバイル）：通常は数MB。ただしプライベートブラウジングやIntelligent Tracking Preventionの影響で挙動が制限されることがある。
IE：世代や設定により変動。古い実装では制限が厳しいことがある。
大量データやバイナリデータの保存には不向きで、より大きな容量が必要な場合は IndexedDB の使用を検討してください。IndexedDB は非同期APIで大容量データ向きです。
パフォーマンスと同期性の注意点
Webストレージ API は同期 API です。つまり、setItem や getItem の呼び出しはメインスレッドで即時実行され、特に大きなデータを書き込む際はUIの遅延を引き起こす可能性があります。頻繁な読み書きや大容量データの操作はパフォーマンス低下を招くため、非同期設計の IndexedDB を使うか、データを分割して扱うことが推奨されます。
セキュリティ上の注意点
XSSに弱い：Webストレージに保存したデータは JavaScript から容易に取得できるため、クロスサイトスクリプティング（XSS）脆弱性が存在するサイトでは、攻撃者により格納データが窃取される危険があります。認証トークンや機密情報（パスワード、生体データ、クレジットカード情報など）を localStorage/sessionStorage に保存することは避けるべきです。
HttpOnlyクッキーとは別物：HttpOnly属性の付いたクッキーは JavaScript からアクセスできません。認証用途のトークンは可能なら HttpOnly+Secure なクッキーで扱うほうが安全です。
同一オリジンポリシー：Webストレージは同一オリジンポリシーに従いますが、サブドメインの違いには注意が必要です（例：example.com と sub.example.com は異なるオリジン）。
CSRFとの関係：CSRF（クロスサイトリクエストフォージェリ）は主に認証済みリクエストが自動で送信されるクッキーに関係します。Webストレージの値は自動送信されないため CSRF の直接の原因にはなりませんが、XSS による攻撃で Webストレージの値を取得し、悪用されるリスクはあります。
クロスウィンドウ／タブの同期
localStorage の更新は同一オリジン内で他のタブやウィンドウに storage イベントとして通知されます。これを利用して、タブ間で簡単な通知やステート同期を実装できます。ただし、同一タブ内での発火はされません（発火元のコンテキストではイベントは発生しない）。
プライベートブラウズやブラウザの制限
プライベート／シークレットモードではブラウザが Web ストレージの保存や永続性を制限したり、セッション単位でしか保存しなかったり、保存容量を大幅に制限することがあります。特に Safari や一部のモバイルブラウザでは、ユーザが長時間放置するとストレージがクリアされることや、サードパーティスクリプトのストレージアクセス自体を制限することがあるため、永続的な保存が前提の設計は避けるべきです。
ブラウザのストレージ管理 API（StorageManager）
近年のブラウザでは navigator.storage.estimate() による使用量/上限の推定や、navigator.storage.persist() による永続化要求（ユーザが拒否する場合あり）を利用できます。これにより、ストレージの残容量をチェックしてから大きなデータを書き込むなどの対策が可能です。しかし、この API も全ブラウザで同等にサポートされているわけではないため、フォールバック処理を用意してください。
実践的な利用ケースと注意点
UI設定（テーマ、表示設定、列幅など）：少量かつ復元が容易なデータ保存に最適。
キャッシュ（APIレスポンスの一部など）：オフライン時の簡易キャッシュとして有用。ただし容量と整合性管理が必要。
フォームの一時保存：入力中の内容の退避に便利。ただしセキュリティ上の配慮（個人情報を含めない等）が必要。
認証情報の保存は避ける：アクセストークンやリフレッシュトークンは HttpOnly のセキュアクッキーや、サーバ側でのセッション管理を検討する。
ベストプラクティス（チェックリスト）
機密データは保存しない。トークンは HttpOnly+Secure クッキーを優先。
大きなデータは IndexedDB を使用する（非同期でパフォーマンスに優れる）。
保存前にデータサイズを概算し、必要なら分割や圧縮を検討する。
入力検証と出力エスケープを徹底し、XSS の入口を封鎖する。
navigator.storage.estimate() を使って残容量を確認し、フォールバック処理を実装する。
localStorage の変更は
storageイベントで監視し、タブ間同期を実装する。プライベートブラウジングやブラウザ差異を想定したフォールバックを用意する。
トラブルシューティング：よくある問題と対策
QuotaExceededError：容量超過。古いデータを削除する、データの圧縮や分割、IndexedDBへ移行する。
private modeで保存できない／即時削除される：ユーザに警告を出すか、サーバ側保存で代替する。
タブ間でデータ同期されない：
storageイベントが発火しているか、同一オリジンかを確認。JSON.parse エラー：保存時に正しく stringify できているか、破損したデータがないかをチェック。
まとめ
Webストレージは実装が簡単で小〜中規模のクライアント側データ保存に便利ですが、同期APIであること、容量制限、XSSに対する脆弱性などの特性を正しく理解することが重要です。重大な機密情報は保存しない、容量が必要な場合や非同期性が重要な場合は IndexedDB を選ぶなど、用途に応じた使い分けとセキュリティ対策を行うことで、安全かつ快適なユーザー体験を提供できます。
参考文献
OWASP: Client Side Storage Cheat Sheet
投稿者プロフィール
最新の投稿
ゲーム2025.12.18街づくりゲームの魅力と設計論：歴史・メカニクス・未来展望- ゲーム2025.12.18恋愛アドベンチャーの魅力と歴史：ゲームデザイン・代表作・文化的影響を徹底解説
- ゲーム2025.12.18恋愛ゲームの歴史・仕組み・最新トレンド：深掘りコラム
- ゲーム2025.12.18育成ゲームの魅力と設計論：歴史・メカニクス・収益化・倫理を深掘り
