Set-Cookieは、HTTPレスポンスでサーバがクライアント（ブラウザ）に新しいCookieを設定したり、既存のCookieを更新したり、削除したりするためのヘッダです。Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Laxのような形で送られ、ブラウザは値と属性を解釈して自身のCookieストアに保管します。現在の仕様はRFC 6265（2011年）で定義され、SameSite属性などのセキュリティ強化を含む改訂作業がRFC 6265bisとして進行中です。ログインセッションの発行、認証トークンの配布、サイト設定の保存など、Webアプリケーションの状態管理開始点となる極めて重要なヘッダで、属性の正しい設定がセキュリティの要となります。
この記事の目次
- 主な属性と意味
- Cookie誕生からセキュリティ強化への流れ
- 発行・更新・削除のパターン
- Cookieヘッダ・Authorizationとの関係
- まとめ
主な属性と意味
Set-Cookieは「name=value」の本体に加え、多数の属性で挙動を制御します。HttpOnly属性を付けるとJavaScriptのdocument.cookieからの読み取り・書き換えができなくなり、XSS（クロスサイトスクリプティング）攻撃でセッショントークンを盗まれるリスクが大幅に低減します。認証用のCookieには必須の属性です。Secure属性を付けるとHTTPS接続でしか送信されなくなり、HTTP通信での盗聴を防げます。現代のHTTPSが標準化された環境では、認証関連Cookieには必ずSecureを付けるのがベストプラクティスです。
SameSite属性はクロスサイトリクエスト時のCookie送信を制御する重要な属性で、Strict・Lax・Noneの3値を取ります。Strictは「他サイトからのリクエストには一切送らない」、Laxは「トップレベルナビゲーション（リンククリック等）の安全なリクエストには送る」、Noneは「常に送る（ただしSecure必須）」という意味です。2020年以降のChromeはSameSite未指定時にLaxをデフォルト適用するようになり、CSRF対策の標準として広く普及しました。他にもExpires/Max-Age（有効期限）、Domain（送信対象ドメイン）、Path（送信対象パス）、__Host-・__Secure-プレフィックスなど、多数の制御オプションがあります。
Cookie誕生からセキュリティ強化への流れ
Set-Cookieは1994年、NetscapeのLou Montulli氏がCookie仕組みを考案した際にレスポンスヘッダとして同時に定められました。当初はname=valueとExpires・Domain・Path・Secureくらいの単純な属性のみでしたが、時代とともにセキュリティ強化のための属性が次々追加されてきました。2000年頃にはMicrosoftがIE6でHttpOnly属性を導入し、JavaScriptからセッションCookieを保護するための仕組みが普及しました。
2011年4月のRFC 6265でCookieの仕様が現代的な形に再整理され、Set-Cookieの構文と属性の解釈が公式に文書化されました。2016年にGoogleがChromeでSameSite属性を実装し、その後2020年頃からSameSite=Laxがデフォルト適用となり、CSRF（クロスサイトリクエストフォージェリ）対策の標準として急速に広まりました。近年は__Host-プレフィックス（最も安全な設定を強制）、__Secure-プレフィックス（Secure属性必須）、CHIPS（Cookies Having Independent Partitioned State）、第三者Cookie廃止議論など、プライバシーとセキュリティの観点からの進化が継続的に行われています。RFC 6265bisとして改訂作業が進行中で、現代Webのプライバシー要件に対応した次世代仕様が議論されています。
発行・更新・削除のパターン
ログイン成功時にサーバがSet-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400のようなレスポンスを返し、以降そのセッションIDで認証状態を維持するのが典型的な使い方です。Max-Age（秒単位の有効期間）またはExpires（絶対時刻）で生存期間を指定し、過ぎたらブラウザが自動的にCookieを破棄します。ログアウト時はSet-Cookie: session=; Max-Age=0; Path=/のように同じ名前で空値・有効期限ゼロを返すと、ブラウザがCookieを削除する仕組みです。
セキュリティの観点からは、認証Cookieはアクセスのたびに新しい値にローテーションする「リフレッシュ」パターンが推奨されます。__Host-id=value; Path=/; Secure; HttpOnly; SameSite=Strictのように__Host-プレフィックスを付けると、Domain属性を持てない・Path=/必須・Secure必須という制約が自動的にかかり、最も安全な設定が強制されます。1つのレスポンスに複数のSet-Cookieヘッダを並べることもでき、Set-Cookie: a=1 Set-Cookie: b=2のように複数のCookieを同時に設定可能です。HTTPヘッダの仕様上、同名のヘッダは通常カンマで結合されますが、Set-Cookieだけは例外で別々の行として扱われる、独特な扱いの歴史的経緯があります。
Cookieヘッダ・Authorizationとの関係
Set-Cookieはサーバからクライアントへの「発行」用ヘッダで、レスポンスにのみ現れます。対するCookieヘッダはクライアントからサーバへの「返送」用で、リクエストに付けて発行済みCookieを送り返す役割です。両者は対になっており、Set-Cookieで発行されたCookieが、その属性に従って次回以降のリクエストでCookieヘッダとして自動送信される、という流れがWebの状態管理の基本パターンです。
Authorizationヘッダは別の認証手段で、Bearer Token・Basic認証・AWS Signatureなど、リクエストごとに認証情報を明示的に付ける方式です。Cookieベースの認証とBearer Tokenベースの認証は、SPAやモバイルアプリでよく議論される選択肢で、それぞれ得手不得手があります。Cookieは自動送信されるためCSRF対策が必須（SameSite属性で対策）ですが、HttpOnlyによりXSS耐性が高くなります。Authorization: Bearerは手動付与でCSRF耐性は自然に高いものの、JavaScriptで保管するためLocalStorage等に置くとXSSで盗まれやすい弱点があります。現代のセキュリティベストプラクティスではHttpOnly Cookieに認証情報を入れる方式が再評価されており、Set-Cookieの属性設定が重要度を増しています。
まとめ
Set-CookieはCookie発行・更新・削除のためのHTTPレスポンスヘッダで、現在はRFC 6265（2011年）で定義されRFC 6265bisで改訂作業中です。HttpOnly・Secure・SameSite（Strict/Lax/None）・Expires/Max-Age・Domain/Path・__Host-/__Secure-プレフィックスといった豊富な属性で、安全性と動作の細部を制御します。Cookieヘッダによる返送と対になって動作し、Authorizationヘッダによる認証と棲み分けながら、現代Webセッション管理のセキュリティの要を担うヘッダとして極めて重要な役割を持ち続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント