- Token漏洩を防ぐ設計は「認証の“鍵”を絶対に落とさないための全体設計」です
- Tokenが漏洩する典型的なパターンをまず知る
- ステップ1:Tokenの「置き場所」を設計する(HttpOnly Cookieを基本にする)
- ステップ2:Web Storageにトークンを保存しないユーティリティ設計
- ステップ3:Tokenを「画面やログに出さない」設計を徹底する
- ステップ4:Tokenの「寿命」を短くする(短期アクセストークン+リフレッシュトークン)
- ステップ5:Tokenを扱うコードを「1箇所」に集約する(ユーティリティ化)
- ステップ6:XSS対策とToken設計をセットで考える(重要な深掘り)
- ステップ7:チームで共有するための「Token取り扱いルール」をコードとドキュメントに刻む
- まとめ:Token漏洩を防ぐ設計は「認証の鍵を守るための、地味だけど決定的に重要な工夫の積み重ね」です
Token漏洩を防ぐ設計は「認証の“鍵”を絶対に落とさないための全体設計」です
業務システムで使われるアクセストークン(JWTなど)は、 ユーザーの認証・権限を表す 「鍵」そのもの です。
- このトークンを持っている人は、ユーザーになりすませる
- このトークンが漏洩すると、攻撃者が自由にAPIを叩ける
- このトークンが長期間有効だと、被害も長期間続く
つまり、「Token漏洩を防ぐ設計」=「システム全体の安全性を守る設計」 です。
ここでは、初心者向けに、 「どこから漏れるのか」→「どう設計で防ぐのか」→「実務で使えるユーティリティ」 という流れでステップバイステップで解説していきます。
Tokenが漏洩する典型的なパターンをまず知る
1. Web Storage(localStorage / sessionStorage)からの漏洩
localStorage.setItem("auth.token", token); // よくある危険パターン
JavaScriptXSS攻撃が成立すると、攻撃者は次のようなコードを書けます。
for (let i = 0; i < localStorage.length; i++) {
const key = localStorage.key(i);
const value = localStorage.getItem(key);
// 攻撃者のサーバーへ送信
}
JavaScriptここにトークンが入っていれば、即漏洩です。
2. URLやログにトークンを載せてしまう
// 危険な例:トークンをクエリパラメータに載せる
const url = `/api?token=${token}`;
console.log("API呼び出し:", url); // ログにトークンが残る
JavaScript- ブラウザの履歴
- サーバーログ
- プロキシログ
などにトークンが残り、後から参照されてしまう可能性があります。
3. ブラウザ拡張や他のスクリプトからの盗み見
トークンをJavaScriptから自由に読める場所に置いておくと、 悪意ある拡張機能やサードパーティスクリプトからもアクセスされる可能性があります。
