先に読むと理解しやすい記事：URL・ドメイン・オリジン / Cookie
保存期間と、誰が読んで送るかを分けて選ぶ
ブラウザには、サイトが設定や状態を保存する複数の方法があります。Cookieは条件に合うHTTPリクエストへブラウザが自動で付ける仕組みです。localStorageとsessionStorageはJavaScriptが名前と値を読み書きする保存領域です。
たとえば表示テーマならlocalStorageへ保存し、ページを開き直して読み出せます。ログイン情報を保存するときは、便利さだけでなく、JavaScriptから読めるか、いつサーバーへ送るか、盗まれた値をどう止めるかも考えます。
localStorageは同じオリジンの画面で共有する
localStorageはオリジンごとに分かれ、同じオリジンの複数ページやタブで同じ保存領域を使います。通常はブラウザを閉じた後も残りますが、利用者の削除やプライベートモードなどで消える場合があるため、永続保存を保証するものではありません。
値は文字列として保存します。次のコードは秘密を含まない表示設定の例です。保存しただけでHTTP通信へ自動追加はされず、サーバーへ送るならアプリのコードが読み出してリクエストを作ります。
説明用の通信例・設定例・擬似コード
localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");
localStorage.removeItem("theme");参照：出典 s1
sessionStorageはオリジンとタブの単位で扱う
sessionStorageは、同じオリジンでもトップレベルのタブごとに保存領域を分けます。同じタブの再読み込みでは残り、通常はタブのページセッション終了時に消えます。サーバーのログインセッションとは別の仕組みです。
新しく開くページにopenerがある場合、開いた元のsessionStorageが初期値としてコピーされることがあります。ただしその後の変更を共有する領域ではありません。復元時の挙動もあるため、単にブラウザを閉じる動作だけを秘密の失効手段にはしません。
参照：出典 s2
タブ限定の保存でも同じページの悪意あるコードは読める
説明用の例として、投稿したHTMLが適切に無害化されず、表示時に攻撃者のJavaScriptが実行される状態を考えます。そのコードは表示ページと同じオリジンで動くため、そのページのlocalStorageやsessionStorageを読めます。
保存してあるBearerトークンを読み、攻撃者の受信先へ送れば、攻撃者は値を取得できます。ネットワーク送信が許されることなども成立条件です。sessionStorageの短い保存期間だけでは、開いているページ内のXSSから守れません。
参照：出典 s4
保存値も利用者が変更できる入力として扱う
確認問題：localStorageのisAdmin=trueを見て管理APIを許可してよいでしょうか。答えは違います。利用者が自分の保存値を変更できるので、APIはサーバー側で認証と権限を確認します。
保存する個人情報を減らし、ログアウト時の削除、共有端末での残存、容量制限や保存禁止時のエラーも確認します。必要ならIndexedDBなど別の保存機能も検討しますが、保存機能を変えるだけで同じオリジンの悪意あるコードを排除できるわけではありません。
出典・確認範囲
- [s1] Web Storage APIMDN / 確認日 2026-11-03
- [s2] Window: sessionStorage propertyMDN / 確認日 2026-11-03
- [s3] Using HTTP cookiesMDN / 確認日 2026-11-03
- [s4] HTML5 Security Cheat SheetOWASP / 確認日 2026-11-03
通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。