Webサーバー・インフラ
クッキー(Cookie)
post:
Cookie(クッキー)は、Webサイトがブラウザへ状態を渡し、条件に合う後続リクエストでブラウザから送り返すための仕組みです。 ログイン状態の維持や表示設定の記憶などに使われます。
Cookieとは?
サーバーはHTTPレスポンスのSet-Cookieヘッダーで、名前と値、適用範囲や有効期限などの属性をブラウザへ渡します。
ブラウザは保存を受け入れたCookieのうち、接続先、パス、HTTPSかどうかなどの条件に一致するものを、後続リクエストのCookieヘッダーへ付けて送信します。
Cookieそのものが利用者の氏名やログイン状態を意味するわけではありません。 サーバー側がCookieの値をどのように扱うかを決めます。多くのログイン機能では、推測されにくいセッションIDをCookieに入れ、利用者情報はサーバー側で管理します。
基本的な流れ
- ユーザーがWebサイトにアクセスする
-
サーバーがレスポンスに
Set-Cookieヘッダーを付けて送る - ブラウザがそのCookieを保存する
-
同じサイトに再度アクセスすると、ブラウザが自動的にそのCookieを
Cookieヘッダーとしてリクエストに含めて送信する
これにより、サーバー側は「このリクエストは以前来たのと同じユーザーだ」と識別できるようになります。
セッションとの関係
Cookieはブラウザ側で管理されるデータであり、セッションはアプリケーションが利用者ごとの状態を管理するための考え方です。 両者は同じものではありません。
一般的な構成では、ブラウザにはセッションIDだけをCookieとして保存し、利用者情報や権限などの実データはサーバー側のセッションストアで管理します。 これにより、ブラウザへ機密情報そのものを渡さずに、リクエストとサーバー側の状態を対応付けられます。
| 項目 | Cookie | サーバーサイドセッションの一般的な構成 |
|---|---|---|
| 状態を管理する場所 | ブラウザ | サーバー側のメモリやデータベースなど |
| ブラウザが送るもの | 送信条件に一致するCookieの名前と値 | Cookieなどで渡されたセッションIDを手掛かりに状態を取得する |
| JavaScriptからのアクセス | HttpOnlyがなければ可能。HttpOnlyを付けると制限できる |
サーバー側の状態そのものには、ブラウザのJavaScriptから直接アクセスできない |
| 代表的な用途 | 表示設定、セッションIDなど | ログイン状態、権限、サーバー側で保持する一時的な状態など |
主な属性
Secure:通常はHTTPSで送信されるリクエストにだけCookieを付けます。HttpOnly:JavaScriptなどの非HTTP APIからCookieへアクセスできないようにします。XSSが起きた場合のCookie窃取リスクを下げますが、XSS自体を防ぐものではありません。SameSite:クロスサイトのリクエストでCookieを付ける範囲を制限します。CSRF対策の一部として役立ちますが、これだけで対策が完了するわけではありません。Domain・Path:Cookieを送るホストやパスの範囲を指定します。Max-Age・Expires:Cookieを保持する期間を指定します。指定がないCookieは、ブラウザが定義するセッションの終了時まで保持されるセッションCookieとして扱われます。
localStorage・sessionStorageとの違い
localStorageとsessionStorageは、HTML Standardで定義されたWeb Storageの仕組みです。
どちらもCookieと同様にブラウザ内へデータを保存しますが、HTTPリクエストへ自動で追加されません。
| 項目 | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| HTTPリクエストへの自動送信 | 送信条件に一致すると自動で送られる | 送られない | 送られない |
| 主な共有範囲 | DomainやPathなどで決まる |
同一オリジンのページ間で共有される | 同一オリジンかつ同じ閲覧コンテキスト内で共有される |
| JavaScriptからのアクセス | HttpOnlyを付けると制限できる |
可能 | 可能 |
| 利用例 | サーバー側で確認するセッションID | 画面設定やJavaScriptで使う保存データ | タブ単位で扱う一時的な入力状態など |
JavaScriptが読み書きするデータの保存にはWeb Storageを使い、サーバーへ自動送信する必要がある識別子にはCookieを使う、といった使い分けが行われます。
Web StorageにはHttpOnlyのようにJavaScriptからの読み出しを制限する属性がないため、認証に使う値をどこへ置くかはアプリケーションの構成と脅威モデルを踏まえて決めます。
実装時に意識する点
- ログイン用のCookieには、原則として
SecureとHttpOnlyを設定する。 - 用途に応じて
SameSiteを選び、重要な操作にはCSRFトークンなども組み合わせる。 - Cookieの値を信頼せず、サーバー側でセッションID、有効期限、権限を検証する。
- Cookieへパスワードや個人情報そのものを保存しない。
参考資料
- RFC 6265: HTTP State Management Mechanism
- IETF: Cookies: HTTP State Management Mechanism
- HTML Standard: Web storage