技術知識・用語集

Webサーバー・インフラ

クッキー(Cookie)

post:

Cookie(クッキー)は、Webサイトがブラウザへ状態を渡し、条件に合う後続リクエストでブラウザから送り返すための仕組みです。 ログイン状態の維持や表示設定の記憶などに使われます。

Cookieとは?

サーバーはHTTPレスポンスのSet-Cookieヘッダーで、名前と値、適用範囲や有効期限などの属性をブラウザへ渡します。 ブラウザは保存を受け入れたCookieのうち、接続先、パス、HTTPSかどうかなどの条件に一致するものを、後続リクエストのCookieヘッダーへ付けて送信します。

Cookieそのものが利用者の氏名やログイン状態を意味するわけではありません。 サーバー側がCookieの値をどのように扱うかを決めます。多くのログイン機能では、推測されにくいセッションIDをCookieに入れ、利用者情報はサーバー側で管理します。

基本的な流れ

  1. ユーザーがWebサイトにアクセスする
  2. サーバーがレスポンスにSet-Cookieヘッダーを付けて送る
  3. ブラウザがそのCookieを保存する
  4. 同じサイトに再度アクセスすると、ブラウザが自動的にそのCookieをCookieヘッダーとしてリクエストに含めて送信する

これにより、サーバー側は「このリクエストは以前来たのと同じユーザーだ」と識別できるようになります。

ブラウザからの初回アクセス、サーバーからのSet-Cookie付き応答、ブラウザでのCookie保存、次回アクセス時のCookieヘッダー送信を4段階で示す図
Cookieの発行から、次回以降のリクエストで送信されるまでの基本的なやり取り

セッションとの関係

Cookieはブラウザ側で管理されるデータであり、セッションはアプリケーションが利用者ごとの状態を管理するための考え方です。 両者は同じものではありません。

一般的な構成では、ブラウザにはセッションIDだけをCookieとして保存し、利用者情報や権限などの実データはサーバー側のセッションストアで管理します。 これにより、ブラウザへ機密情報そのものを渡さずに、リクエストとサーバー側の状態を対応付けられます。

ブラウザがセッションIDだけをCookieとしてWebサーバーへ送り、Webサーバーがサーバー側のセッションストアに保存された利用者ID、権限、有効期限などの実データを照合する構成図
CookieはセッションIDを運び、実データはサーバー側のセッションストアで管理する
項目 Cookie サーバーサイドセッションの一般的な構成
状態を管理する場所 ブラウザ サーバー側のメモリやデータベースなど
ブラウザが送るもの 送信条件に一致するCookieの名前と値 Cookieなどで渡されたセッションIDを手掛かりに状態を取得する
JavaScriptからのアクセス HttpOnlyがなければ可能。HttpOnlyを付けると制限できる サーバー側の状態そのものには、ブラウザのJavaScriptから直接アクセスできない
代表的な用途 表示設定、セッションIDなど ログイン状態、権限、サーバー側で保持する一時的な状態など

主な属性

  • Secure:通常はHTTPSで送信されるリクエストにだけCookieを付けます。
  • HttpOnly:JavaScriptなどの非HTTP APIからCookieへアクセスできないようにします。XSSが起きた場合のCookie窃取リスクを下げますが、XSS自体を防ぐものではありません。
  • SameSite:クロスサイトのリクエストでCookieを付ける範囲を制限します。CSRF対策の一部として役立ちますが、これだけで対策が完了するわけではありません。
  • DomainPath:Cookieを送るホストやパスの範囲を指定します。
  • Max-AgeExpires:Cookieを保持する期間を指定します。指定がないCookieは、ブラウザが定義するセッションの終了時まで保持されるセッションCookieとして扱われます。

localStorage・sessionStorageとの違い

localStoragesessionStorageは、HTML Standardで定義されたWeb Storageの仕組みです。 どちらもCookieと同様にブラウザ内へデータを保存しますが、HTTPリクエストへ自動で追加されません。

項目 Cookie localStorage sessionStorage
HTTPリクエストへの自動送信 送信条件に一致すると自動で送られる 送られない 送られない
主な共有範囲 DomainPathなどで決まる 同一オリジンのページ間で共有される 同一オリジンかつ同じ閲覧コンテキスト内で共有される
JavaScriptからのアクセス HttpOnlyを付けると制限できる 可能 可能
利用例 サーバー側で確認するセッションID 画面設定やJavaScriptで使う保存データ タブ単位で扱う一時的な入力状態など

JavaScriptが読み書きするデータの保存にはWeb Storageを使い、サーバーへ自動送信する必要がある識別子にはCookieを使う、といった使い分けが行われます。 Web StorageにはHttpOnlyのようにJavaScriptからの読み出しを制限する属性がないため、認証に使う値をどこへ置くかはアプリケーションの構成と脅威モデルを踏まえて決めます。

実装時に意識する点

  • ログイン用のCookieには、原則としてSecureHttpOnlyを設定する。
  • 用途に応じてSameSiteを選び、重要な操作にはCSRFトークンなども組み合わせる。
  • Cookieの値を信頼せず、サーバー側でセッションID、有効期限、権限を検証する。
  • Cookieへパスワードや個人情報そのものを保存しない。

参考資料

技術知識・用語集に戻る