はじめに
HTTPはステートレスなプロトコルです。
つまり、1回のリクエストとレスポンスの間に状態を保持しません。
しかしWebアプリでは「ログイン状態の維持」や「カート情報の保持」など、継続的な状態管理が必要です。
そのために使われる仕組みが セッション（Session） です。
1. セッションの目的
-
ユーザー識別
- 同じブラウザからの一連のリクエストをひも付ける
-
状態管理
- ログイン状態、ショッピングカート、入力フォームの一時保存
-
セキュリティ
- 認証後の状態を安全に保持し、不正アクセスを防ぐ
2. セッションの仕組み（基本フロー）
3. セッションIDの管理方法
| 方法 | 説明 | 利点 | 注意点 |
|---|---|---|---|
| Cookieベース | CookieにセッションIDを保存 | 標準的・自動送信 |
HttpOnly/Secure必須 |
| URL埋め込み | URLパラメータにIDを付加 | Cookie無効環境でも可 | リンク共有で漏えいリスク大 |
| Web Storage | localStorage/sessionStorageに保存 | 手動制御可能 | XSSに弱い |
4. セキュリティリスクと対策
リスク
-
セッションハイジャック：IDが盗まれ、なりすまされる
-
セッション固定攻撃：攻撃者が予測可能なIDを利用
-
XSSや盗聴によるCookie漏えい
対策
-
セッションIDを十分に長く・ランダムに生成
-
HTTPSを必須化しSecure属性を設定
-
HttpOnly属性でJSからのアクセスを禁止
-
SameSite属性でCSRFを防止
-
ログインや権限昇格時にセッションID再生成
-
一定時間操作がない場合は自動タイムアウト
5. セッション方式とJWTの比較
| 項目 | セッション方式 | JWT方式 |
|---|---|---|
| 状態保持 | サーバ側 | クライアント側（トークン内） |
| 無効化 | サーバ側で即時可能 | トークン期限切れまで有効 |
| 主な用途 | 従来型Webアプリ | SPA / API認証 |
まとめ
-
Webアプリのセッションはユーザー状態を安全に維持するための仕組み
-
安全な運用にはHTTPS＋Cookie属性設定＋ID再生成＋期限管理が必須
-
モダンアプリではJWTとの比較検討も重要