Set-Cookie
Set-Cookie
は HTTP のレスポンスヘッダーで、サーバーからユーザーエージェントへクッキーを送信するために使用され、ユーザーエージェントはそれを後でサーバーに送り返すことができます。
詳細については、HTTP クッキーのガイドを参照してください。
ヘッダー種別 | レスポンスヘッダー |
---|---|
禁止ヘッダー名 | いいえ |
構文
Set-Cookie: <cookie-name>=<cookie-value> Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date> Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit> Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value> Set-Cookie: <cookie-name>=<cookie-value>; Secure Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None // 以下の例のように、複数のディレクティブも利用することができます。 Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
ディレクティブ
<cookie-name>=<cookie-value>
- クッキーは名前と値の組で始まります。
<cookie-name>
は任意の US-ASCII 文字の集合で、制御文字、空白、タブを除いたものです。( ) < > @ , ; : \ " / [ ] ? = { }
のような区切り文字も含めることができません。<cookie-value>
は任意で二重引用符で囲むことができ、制御文字、ホワイトスペース、二重引用符、カンマ、セミコロン、バックスラッシュを除くすべての US-ASCII 文字が利用できます。 エンコーディング: 多くの実装ではクッキーの値に URL エンコーディングを施しますが、 RFC の仕様書では要求されていません。これは <cookie-value> に許可された文字についての要件を満足させるのに役立ちます。__Secure-
の接頭辞:__Secure-
(接頭辞にダッシュを含む) で始まるクッキー名は、secure
フラグを設定することが必要で、安全なページ (HTTPS) でなければなりません。__Host-
の接頭辞:__Host-
で始まるクッキー名は、secure
フラグを設定し、安全なページ (HTTPS) から読み込む必要があり、ドメインを指定することができず (従ってサブドメインにも送られません)、パスが/
で終わる必要があります。
Expires=<date>
省略可-
クッキーの有効期限で、 HTTP の日時タイムスタンプです。詳細な書式は
Date
を参照してください。指定されなかった場合は、クッキーはセッションクッキーの寿命になります。セッションはクライアントが終了したときに終了するので、セッションクッキーはその時点で削除されます。
警告: 多くのウェブブラウザーはセッション復元と呼ばれる機能を持っており、これによってすべてのタブを保存し、次回ブラウザーを起動したときに復元することができます。ブラウザーを実際には閉じていないかのように、セッションクッキーも復元されます。
有効期限が設定されていた場合、期限はサーバーではなく、クッキーが設定されているクライアントからの相対時刻で設定されます。
Max-Age=<number>
省略可- クッキーの期限までの秒数です。ゼロまたは負の数値の場合は、クッキーは直ちに期限切れになります。
Expires
およびMax-Age
の両方が設定されていたら、Max-Age
が優先されます。 Domain=<domain-value>
省略可- クッキーを送信する先のホストです。
- 指定されなかった場合は、既定で現在の文書の URL におけるホスト名の部分になり、サブドメインを含みません。
- 初期の仕様書とは逆に、ドメイン名の前のドット (
.example.com
) は無視されます。 - 複数のホストやドメインの値を指定することはできませんが、ドメインが指定された場合、すべてのサブドメインが常に含まれます。
Path=<path-value>
省略可- リクエストの URL に含まれるべきパスです。含まれていないと、ブラウザーは
Cookie
ヘッダーを送信しません。 - スラッシュ ("/") の文字はディレクトリ区切りとして解釈され、サブディレクトリも同様に一致します (例えば
Path=/docs
であれば、/docs
,/docs/Web/
,/docs/Web/HTTP
はすべて一致します)。 Secure
省略可- セキュアクッキーは、リクエストが SSL と HTTPS プロトコルを使用して行われた場合にのみサーバーに送信されます。ただし HTTP クッキーは、例えば情報が暗号化されないなど、安全ではない仕組みを継承しているので、機密な情報や敏感な情報を転送したり格納したりしないようにしてください。
メモ: 安全ではないサイト (
http:
) はSecure
ディレクティブを付けてクッキーを設定することができなくなりました (Chrome 52 以降および Firefox 52 以降の新機能). HttpOnly
省略可- JavaScript が
Document.cookie
プロパティなどを介してこのクッキーにアクセスすることを禁止します。HttpOnly で作成されたクッキーは、JavaScript で開始されたリクエスト、例えば、XMLHttpRequest.send()
やfetch()
と共に送信されます。これにより、クロスサイトスクリプティング (XSS) の攻撃を軽減します。 SameSite=<samesite-value>
省略可-
Strict
: ブラウザは same-site のリクエスト(つまり、クッキーを設定したのと同じサイトから発信されたリクエスト)に対してのみクッキーを送信します。リクエストが現在のURLとは異なるURLから発生した場合、SameSite=Strict
属性を持つクッキーは送信されません。Lax
: 画像やフレームをロードするための呼び出しなどのクロスサイトサブリクエストではクッキーが抑止されますが、ユーザーがリンクをクリックするなどして外部サイトからURLに移動すると送信されます。None
: ブラウザはクロスサイトと same-site の両方のリクエストでクッキーを送信します。
クッキーがオリジン間リクエストで送信されないことを主張することで、クロスサイトリクエストフォージェリ攻撃 (CSRF) に対していくらか防御することができます。
ブラウザーは クッキーに
SameSite=Lax
の既定値を持たせるよう移行しつつあります。オリジンをまたいでクッキーを送信する必要がある場合、None
ディレクティブを用いて SameSite の制約を外してください。None
ディレクティブはSecure
属性を必要とします。
例
セッションクッキー
セッションクッキーはクライアントが終了したときに削除されます。 Expires
や Max-Age
ディレクティブを指定しないとクッキーはセッションクッキーになります。
Set-Cookie: sessionId=38afes7a8
永続的クッキー
永続的クッキーは、クライアントが終了したときに期限切れにならず、特定の期限 (Expires
) または特定の時間が過ぎた後 (Max-Age
) に期限切れになります。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
Set-Cookie: id=a3fWa; Max-Age=2592000
不正なドメイン
オリジンのサーバーを含まないドメインに所属するクッキーは、ユーザーエージェントが拒否します。
次のクッキーは originalcompany.com
でホストされたサーバーから設定しようとすると拒否されます。
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
提供するドメインのサブドメインへのクッキーは拒否されます。
以下のクッキーは、 example.com
にホスティングされたサーバーからセットされた場合は拒否されます。
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
クッキーの接頭辞
__Secure-
または __Host-
の接頭辞が付いたクッキー名は、安全な (HTTPS の) オリジンから secure
ディレクティブを設定した場合のみ使用することができます。
加えて、 __Host-
の接頭辞が付いたクッキーは、 /
(ホストの任意のパスという意味) を持つ必要があり、 Domain
ディレクティブを持つことができません。
クッキーの接頭辞を実装していないクライアントでは、これらの保証を受けることができず、クッキーは常に受け入れられます。
// どちらも安全な (HTTPS の) オリジンから受け入れられます Set-Cookie: __Secure-ID=123; Secure; Domain=example.com Set-Cookie: __Host-ID=123; Secure; Path=/ // Secure ディレクティブが無いため、拒否されます Set-Cookie: __Secure-id=1 // Path=/ ディレクティブが無いため、拒否されます Set-Cookie: __Host-id=1; Secure // Domain を設定したため、拒否されます Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com
仕様書
仕様書 | 題名 |
---|---|
RFC 6265, セクション 4.1: Set-Cookie | HTTP State Management Mechanism |
draft-ietf-httpbis-rfc6265bis-02 | Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies |
ブラウザーの互換性
BCD tables only load in the browser
このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 https://github.com/mdn/browser-compat-data をチェックアウトしてプルリクエストを送信してください。
互換性のメモ
- Chrome 52 および Firefox 52 以降、セキュリティで保護されていないサイト (
http:
) では、 "secure" ディレクティブ付きでクッキーを設定することはできなくなりました。