Cookie とセッション

なぜ Cookie が要るのか

HTTP は ステートレスです。1 回のリクエストとレスポンスで完結し、サーバは前回の通信を覚えていません。だからログインに成功しても、次のページ要求は「初対面」として処理され、誰なのか分からなくなります。

そこで、最初の 1 回だけ本人確認をして、以降は短い合言葉を毎回提示する流れにします。この合言葉をブラウザとサーバの間で持ち回る運び役が Cookie です。

• Cookie は「認証方式」ではなく、データを往復させる運搬手段にすぎない。
• 中に何を入れるか（後述のセッション ID など）が本質。

Cookie の仕組み

Cookie のやり取りは HTTP ヘッダだけで成立します。サーバが Set-Cookie で渡し、ブラウザが次回から Cookie ヘッダで送り返します。

# サーバ → ブラウザ（ログイン成功時）
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

# 以降、ブラウザ → サーバ（同じサイト宛に自動で付く）
GET /mypage HTTP/1.1
Cookie: session_id=abc123

ポイントは、一度受け取った Cookie をブラウザが同じサイト宛のリクエストに自動で付け続けることです。開発者が JavaScript で何もしなくても付与されます。この「自動で付く」性質が便利な一方、後述の CSRF というリスクの原因にもなります。

サーバ側セッションとセッション ID

ログイン後の「あなたは誰か」という情報をどこに置くかが設計の分かれ目です。基本形は次のとおりです。

• ユーザー ID や権限などの正体はサーバ側に保存する（メモリ、DB、Redis など）。
• ブラウザには中身のないランダムなセッション ID だけを Cookie で渡す。
• セッション ID は、サーバ内のデータを引くための「ロッカーの鍵」。

この方式なら、ブラウザに渡る Cookie には意味のない文字列しか入らないので、盗み見られても直接は中身が分かりません。また、サーバ側のデータを消せば即座にログアウトを強制できます。

// ログイン：本人確認できたらセッションを作り、ID を Cookie で渡す
app.post("/login", async (req, res) => {
  const user = await verifyPassword(req.body.id, req.body.password);
  if (!user) return res.status(401).send("Unauthorized");
  const sid = createSession(user.id); // サーバ側ストアに sid → user.id を保存
  res.cookie("session_id", sid, { httpOnly: true, secure: true, sameSite: "lax" });
  res.send("ok");
});

// 保護ページ：届いた Cookie の ID でサーバ側を引き直す
app.get("/mypage", (req, res) => {
  const userId = lookupSession(req.cookies.session_id);
  if (!userId) return res.status(401).send("Login required");
  res.send("Hello user " + userId);
});

主要な属性（HttpOnly / Secure / SameSite）

Cookie の安全性は属性で決まります。最低限おさえるべきものを整理します。

属性	役割	ひとこと
HttpOnly	JavaScript（document.cookie）から読めなくする	XSS で盗まれにくくする最重要属性
Secure	HTTPS のときだけ送信する	平文での漏洩を防ぐ
SameSite	別サイト発のリクエストに付けない	Lax / Strict で CSRF を緩和
Max-Age / Expires	有効期限を決める	無指定だとブラウザを閉じるまで（セッション Cookie）

SameSite には主に 3 つの値があります。Strict は別サイトからの遷移では一切送らず最も厳格、Lax は通常のリンク遷移では送る現実的な既定値、None はクロスサイトでも送る代わりに Secure 必須です。

つまずきポイント：CSRF と有効期限

Cookie が自動で送られる性質は、**CSRF（クロスサイトリクエストフォージェリ）**の温床になります。利用者がログイン中に罠ページを開くと、そこから本物サイトへ勝手にリクエストが飛び、Cookie も自動で付いてしまうためです。

• 対策の基本は SameSite=Lax（または Strict）で、別サイト発のリクエストに Cookie を付けないこと。
• 重要操作には別途 CSRF トークンを併用するとさらに堅い。

有効期限の指定も実務では重要です。Max-Age を付けない Cookie はブラウザを閉じると消える（セッション Cookie）ため、「ログイン状態を保持する」チェックの有無で使い分けます。

ステータスコード 401（未認証）と 403（権限なし）の違いなど土台は HTTP を、別オリジンの API を叩く際の制約は CORS もあわせてどうぞ。