Cookie・セッション管理シリーズ 第1回 / 全5回

Cookieとは何か？ HTTPが状態を保持する仕組み

Webサイトにログインした後、ページを移動してもログイン状態が続く。これは当たり前のように見えるが、HTTPそのものは前のリクエストを覚えていない。

では、Webアプリケーションはどうやって「さっきログインしたユーザー」だと判断しているのだろうか？

この記事では、Cookieの基本的な役割と、Cookieを利用したサーバー側セッション管理を、HTTPヘッダーとアーキテクチャ図で解説する。

本記事の図は、CookieにセッションIDを保存する一般的な構成例。Cookie自体がログイン機能を提供するわけではなく、認証方式によって実装は異なる。

1. HTTPはステートレスなプロトコル

HTTPでは、それぞれのリクエストが独立して扱われる。あるリクエストが成功したからといって、次のリクエストに「誰がログインしたか」という情報が自動的に引き継がれるわけではない。

ここでいう「ステートレス」は、サーバーが状態を一切保存できないという意味ではない。HTTPのリクエスト間で状態を自動的に共有する仕組みがない、という意味だ。

2. Cookieとは何か

Cookieは、サーバーがHTTPレスポンスでブラウザに保存を指示できる小さなデータだ。ブラウザは保存したCookieを、ドメイン・パス・有効期限・セキュリティ属性などの条件に従って、後続のHTTPリクエストに付けて送信する。

サーバーは Set-Cookie レスポンスヘッダーを使う。

Copied!!
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
Content-Type: text/html

ブラウザは条件が一致する後続のリクエストで Cookie リクエストヘッダーを使う。

Copied!!
GET /mypage HTTP/1.1
Host: example.com
Cookie: session_id=abc123

ここでの session_id=abc123 は説明用のダミー値。実際のセッションIDには、推測困難なランダム値を使う必要がある。

Cookieの保存場所はどこ？

Cookieはブラウザ側で管理される。サーバーが送信した Set-Cookie をブラウザが解釈して保存し、条件を満たすリクエストで自動的に送信する。CookieはHTTPの仕組みであり、JavaScriptで毎回ヘッダーを組み立てる必要はない。

ただし、Cookieは無条件にすべてのリクエストへ送信されるわけではない。例えば Secure が付いたCookieは原則HTTPS接続で送信され、SameSite はクロスサイトリクエストでの送信条件に影響する。

3. CookieとセッションIDでログイン状態を維持する

ログイン情報をCookieに丸ごと保存する必要はない。一般的なサーバー側セッション方式では、CookieにはセッションIDを保存し、ユーザーIDなどのセッション情報はサーバー側で管理する。

ログインから認証済みリクエストまで

この構成では、サーバーは受け取ったセッションIDを手がかりに、リクエストがどのユーザーのものかを判定できる。

重要なのは、Cookieは識別子を運ぶ手段であり、セッションの有効性を保証するものではないという点だ。サーバーは毎回、セッションIDが有効かどうかを確認する必要がある。

4. Cookieとセッションは同じものではない

例えば、ブラウザからCookieを削除しても、サーバー側のセッション情報がすぐに消えるとは限らない。反対に、Cookieがブラウザに残っていても、サーバー側のセッションが失効していれば認証は通らない。

5. Cookieがないと状態管理できない？

そんなことはない。認証情報を Authorization ヘッダーで送る方式などもある。Cookieは、ブラウザがリクエストに値を自動付与できることが大きな特徴だ。

Cookieを使う方式でも、サーバー側にセッションを置く場合と、署名付きトークンなどをCookieに保存する場合がある。Cookieはデータの受け渡し方法であり、認証方式そのものではない。

6. ブラウザでCookieを確認してみる

Chromeなら、開発者ツールを使って動作を観察できる。

1. 開発者ツールを開き、Application → Storage → Cookies を選ぶ。
2. 対象サイトのCookie名、値、ドメイン、パス、有効期限、属性を確認する。
3. Network タブでHTTPリクエストを選び、Cookie リクエストヘッダーを確認する。
4. ログインレスポンスに Set-Cookie があるかを確認する。

注意：セッションIDは認証に使われる秘密情報になり得る。実際の値をスクリーンショットやブログ記事に公開しないこと。

まとめ

• HTTPはリクエスト間の状態を自動的には保持しない。
• サーバーは Set-Cookie でブラウザに値を保存させられる。
• ブラウザは条件を満たす後続のリクエストで Cookie ヘッダーを送信する。
• サーバー側セッション方式では、Cookieに保存したセッションIDを使ってユーザーを識別する。
• Cookieの存在と、サーバー側セッションの有効性は別問題である。

次回予告：有効期限付きCookieはどう動くのか？

次回は Expires と Max-Age の違い、ブラウザが期限切れを判定する仕組み、そしてCookieの期限とサーバー側セッションの期限が一致しない場合の挙動を掘り下げる。

参考資料

• MDN: HTTP cookies
• MDN: Set-Cookie
• RFC 6265: HTTP State Management Mechanism