先に読むと理解しやすい記事：HTTP・HTTPS / URL・ドメイン・オリジン

Cookieはブラウザが保存し、条件に合う通信へ付ける値

Cookieは、ブラウザが名前と値を保存し、条件に合う宛先へのHTTPリクエストに付けて送る仕組みです。ログイン状態の識別や表示設定などに使います。Cookieそのものが、ログインの正しさを保証するわけではありません。

たとえばサーバーがログイン成功時に、ランダムなセッションIDをCookieとして保存させます。次に利用者がマイページを開くと、ブラウザはサーバーへのリクエストにその値を付けます。サーバーが値を照合して利用者を特定します。

参照：出典 s1

Set-Cookieは保存の指示、Cookieは送信する値

サーバーはレスポンスのSet-Cookieヘッダーで、ブラウザへ値と保存・送信条件を伝えます。ブラウザは受理したCookieを保存し、条件が合う後のリクエストのCookieヘッダーに名前と値を入れます。

次のabc123は説明用の値で、本番のセッションIDには推測しにくい十分な乱数を使います。Secureなどの属性はブラウザが判断に使う情報であり、後のCookieヘッダーにそのまま並べてサーバーへ送り返すものではありません。

説明用の通信例・設定例・擬似コード

// レスポンスで保存を指示
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

// 後のリクエストで値を送信
Cookie: session=abc123

参照：出典 s1

DomainとPathは送信先の範囲を指定する

Domainを省略すると、Cookieを設定したホストだけを対象にするCookieになります。Domain=example.comを指定すると、受理可能な範囲内でexample.comとそのサブドメインへ送る対象になります。ブラウザは無関係なドメイン用の指定を自由には受け入れません。

Path=/accountなら、そのパスに一致する範囲のリクエストが送信対象になります。ただしPathは、同じオリジンのコードから秘密を隔離するための強い境界ではありません。Cookieはオリジンと違って、ポートごとには分離されない点にも注意します。

参照：出典 s2

SecureとHttpOnlyは守る対象が違う

Secureは、通常HTTPSの通信にCookieを限定する属性です。HttpOnlyは、document.cookieなどのJavaScript用の機能からCookieの値を読めなくする属性です。どちらもログイン用Cookieで重要ですが、役割は異なります。

HttpOnlyでも、条件に合うHTTPリクエストにはブラウザがCookieを付けます。サイト内でXSSが起きて攻撃者のコードが動くと、そのコードは利用者のブラウザからAPIへ更新を依頼できます。Cookieの文字列を盗めなくても、利用者として操作される場合があります。

参照：出典 s2

SameSiteは別サイトを起点とするCookie送信を制限する

SameSite=Strictは同一サイトの文脈に送信を強く制限します。Laxは同一サイトの通信に加え、別サイトからの通常のGETによるトップレベル移動などで送信を認めます。トップレベル移動は、画像などの埋め込みではなく、表示中のページ自体を切り替える移動です。

Noneはクロスサイトでの送信を許す指定ですが、Secureも必要です。ブラウザの第三者Cookie制限などで、送信がさらに制限される場合もあります。属性を省略したときの既定動作に依存せず、必要な条件を明記します。

同じサイトでも別オリジンの場合があります。SameSiteだけで、同一サイトの侵害されたサブドメインからのすべての攻撃を防げるとは考えません。更新API側のCSRF対策も必要です。

参照：出典 s2

Cookieの期限とログインの期限を別に管理する

Max-Ageは保存期間を秒で指定し、Expiresは日時で指定します。両方があるとMax-Ageが優先されます。どちらもないセッションCookieは、ブラウザのセッション終了時に削除される扱いですが、セッション復元で再利用される場合があります。

ログアウトでは、同じ名前・Domain・Pathを指定してMax-Age=0などでCookieを削除します。同時にサーバー側のセッションも無効にします。ブラウザのCookie削除だけでは、盗まれたセッションIDによる別環境からの利用を止められません。

参照：出典 s1

値を改変されても権限が増えない設計にする

説明用の例として、role=adminというCookieだけで管理者と判断する実装を考えます。攻撃者が自分のCookieの値を変更すると、サーバーが管理者操作を許可してしまいます。Cookieの値は利用者側から操作できる入力として扱います。

確認問題：HttpOnlyにしたroleなら、サーバーが無条件に信用してよいでしょうか。答えはよくありません。JavaScriptからの読み書きを制限しても、攻撃者自身によるHTTPリクエストの作成までは防げません。サーバーで管理する権限や、検証済みの認証情報に基づいて判断します。

参照：出典 s1 / 出典 s2

出典・確認範囲

  1. [s1] Using HTTP cookiesMDN / 確認日 2026-11-03
  2. [s2] Set-Cookie headerMDN / 確認日 2026-11-03
未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。