Cookie・セッション・SameSite の基礎 - Secure / HttpOnly と CSRF・CORS の関係

ログイン状態の維持、CSRF対策、クロスオリジンでの認証——どれも根っこは Cookie・セッション・SameSite の理解です。ここが曖昧だと「なぜかログインが切れる」「なぜかCookieが送られない」で延々ハマります。この記事では、MDN・RFC 6265bis・OWASP を一次ソースに、Web認証の基礎を整理します。

Cookieの基本

サーバーはレスポンスの Set-Cookie ヘッダでCookieを設定し、ブラウザは以降のリクエストに Cookie ヘッダで自動送信します。1つのレスポンスに Set-Cookie を複数並べれば複数のCookieを設定できます。

Set-Cookie: sessionid=abc123
Set-Cookie: prefs=dark; Max-Age=2592000

有効期限とスコープ

• Expires: 絶対日時で失効を指定
• Max-Age: 相対秒数で指定。両方あれば Max-Age が優先
• どちらも無ければセッションCookie（ブラウザ終了で消える。ただし「セッション復元」機能で残ることがある）
• Domain: 省略するとそのホストのみ。Domain=example.com を付けるとサブドメインにも送られる（意図せず広げる事故が多い）
• Path: パスのプレフィックス一致。なお Path はセキュリティ境界ではない（同一オリジンの別パスからJSでアクセス可能）

セキュリティ属性: Secure と HttpOnly

重要なのは、HttpOnly でもHTTPリクエストには送られること。fetch の通信にCookieは付きますが、JSから値を読むことだけが封じられます。認証用Cookieは原則 Secure; HttpOnly を付けます。

SameSite: Strict / Lax / None

SameSite は「クロスサイトのリクエストでCookieを送るか」を制御します。CSRF対策の要です。

• Strict: クロスサイトでは一切送らない（最も安全。ただし外部リンクから来ると未ログイン扱いになる）
• Lax: トップレベルのGETナビゲーション（アドレスバーが変わる遷移）だけ許可。大半のCSRFを緩和しつつ実用的
• None: クロスサイトでも送る。Secure が必須（SameSite=None 単体はブラウザに拒否される）

# 認証セッション(推奨形)
Set-Cookie: session=38afes7a8; Secure; HttpOnly; SameSite=Strict; Path=/
 
# サードパーティ埋め込み等でクロスサイト送信が要る場合
Set-Cookie: widget=7yjgj; Secure; HttpOnly; SameSite=None

セッション管理

典型的なサーバー側セッションは、セッションIDだけをCookieで渡し、本体（ユーザー情報など）はサーバー側ストア（DB・Redis等）に置きます。

• セッションIDは予測不可能な値（CSPRNGで十分なエントロピー）にする
• ログイン成功時にセッションIDを再生成する——これがセッション固定攻撃の根本対策。Secure や HttpOnly を付けるだけでは固定攻撃は防げません
• セッション認証情報を localStorage 等のWeb Storageに置かない（XSSで抜かれる）

トークンベース（JWTなど）との使い分けはJWT の仕組みと正しい使い方を、パスワードに依存しない認証はパスキー / WebAuthnもどうぞ。

CSRFとの関係（SameSiteだけでは不十分）

SameSite=Strict/Lax はクロスサイトからの自動Cookie送信を抑えるので、CSRFを大きく緩和します。ただしこれ単体では守りきれません。

• Lax は安全なGETを通す: GETで状態を変更するAPIがあると素通りする
• サブドメインは同一サイト扱い: evil.example.com を乗っ取られると app.example.com 宛に送られうる
• 古い/組み込みブラウザが SameSite を無視することがある

結論として、SameSiteは多層防御の一層。状態変更は CSRFトークン（またはDouble Submitパターン）と併用し、GETで副作用を起こさない設計を守ります。

CORSとCookieの関係

クロスオリジンの fetch でCookieを送受信するには、4つすべてが必要です（CORS の仕組みの続きとして重要）。

どれか1つ欠けても送られません。とくに「クライアントで include にしたのにサーバー側の Allow-Credentials を忘れる」「Allow-Origin: * のまま」という取りこぼしが定番です。

Cookieプレフィックス: __Host- と __Secure-

名前の先頭に特定の接頭辞を付けると、ブラウザが属性の条件を強制します（RFC 6265bis）。

Set-Cookie: __Host-SID=<token>; Secure; HttpOnly; SameSite=Strict; Path=/

認証Cookieには __Host- を使うと、Domain偽装やHTTP経由の上書きを構造的に防げます。

よくある落とし穴

• Domain の付け忘れ/付けすぎ: 未指定はホスト限定、指定はサブドメインに拡散。意図と逆になりがち
• SameSite=None に Secure なし: 拒否される。HTTP環境では None は使えない
• セッション固定をCookie属性で防ごうとする: 防げない。ログイン後のID再生成が必須
• CORSの認証条件を一部だけ満たす: 4条件は全部そろえる
• Allow-Origin: * と credentials の併用: ブラウザが拒否。具体的オリジンを返す

まとめ

• Cookieは Set-Cookie で設定し自動送信。Domain 未指定はホスト限定、Max-Age が Expires に優先
• 認証Cookieは Secure; HttpOnly。HttpOnly でも通信には乗る（JSが読めないだけ）
• SameSite は Strict/Lax/None。None は Secure 必須。Chrome 80以降は未指定＝Lax
• セッションはIDだけCookie・本体はサーバー。ログイン後にID再生成で固定攻撃を防ぐ
• SameSiteだけでCSRFは防ぎきれない。トークンと併用。クロスオリジンCookieはCORSの4条件
• 認証Cookieは __Host- 接頭辞でさらに堅く

属性ひとつの意味を押さえるだけで、「ログインが切れる」「Cookieが送られない」の大半は理由が見えてきます。既定に委ねず、明示して堅く設定するのが要です。

参考リンク

• HTTP Cookie（MDN）
• Set-Cookie（MDN）
• SameSite cookies explained（web.dev）
• Session Management Cheat Sheet（OWASP）
• CORS の仕組みとハマりどころ（当ブログ）
• JWT の仕組みと正しい使い方（当ブログ）