- Web Storageに機密情報を保存しない設計は「ブラウザ側を“信頼しすぎない”ための基本セキュリティ方針です」
- Web Storageが危険になりうる理由を整理する
- ステップ1:「機密情報」と「非機密情報」を明確に分ける
- ステップ2:認証情報は「Cookie+HttpOnly」を基本にする
- ステップ3:Web Storageに「何を保存してよいか」を設計する
- ステップ4:安全なWeb Storageユーティリティを作る(機密情報を扱わない前提)
- ステップ5:機密情報を扱うコードからWeb Storageを完全に排除する
- ステップ6:XSSとWeb Storageの関係を理解しておく(深掘り)
- ステップ7:チームで共有するための「ルール」と「コメント」をコードに残す
- まとめ:Web Storageに機密情報を保存しない設計は「ブラウザ側のリスクを前提にした堅実な防御線」
Web Storageに機密情報を保存しない設計は「ブラウザ側を“信頼しすぎない”ための基本セキュリティ方針です」
業務システムでは、localStorage や sessionStorage といった Web Storage を使う場面が多くあります。
- 画面状態(タブの選択、フィルタ条件)を保存する
- 一時的な設定値を保持する
- ユーザーのUI好み(テーマ、言語)を記憶する
とても便利ですが、ここで絶対にやってはいけないことがあります。 それが 「機密情報をWeb Storageに保存する」 という行為です。
機密情報とは、例えば次のようなものです。
- アクセストークン(JWTなど)
- リフレッシュトークン
- パスワードや認証情報
- 個人情報(マイナンバー、クレジットカード番号など)
ここでは、初心者向けに、 「なぜ危険なのか」→「何を保存してよいか/ダメか」→「安全なユーティリティ設計」 という流れでステップバイステップで解説していきます。
Web Storageが危険になりうる理由を整理する
まず、Web Storageの特徴を押さえます。
- JavaScriptから簡単に読み書きできる
localStorage.setItem("key", "value");localStorage.getItem("key"); - ブラウザに長期間残る(特にlocalStorage) ユーザーが消さない限り残り続けます。
- XSS攻撃が成立すると中身を丸ごと盗まれる 攻撃者がページ内でJavaScriptを実行できると、
localStorageの中身を自由に読み取れます。
つまり、Web Storageは
「ブラウザ内で誰でも(JavaScriptなら)読める引き出し」
のようなものです。
この引き出しに アクセストークンや機密情報を入れてしまうと、 XSS攻撃が成立した瞬間に“全部持っていかれる” ことになります。
