Cookie: HTTP 状態管理機構

2.1. 適合基準

この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、 "MAY"、および "OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] で説明されるように 解釈されるものとします。¶

アルゴリズムの一部として命令形で表現された要件（たとえば「先頭の空白文字をすべて 取り除く」や「false を返してこのアルゴリズムを中止する」など）は、 そのアルゴリズムを導入する際に使用されたキーワード（"MUST"、"SHOULD"、"MAY" など）の 意味で解釈されます。¶

アルゴリズムまたは特定のステップとして表現された適合要件は、 最終結果が等価である限り、任意の方法で実装できます。特に、 この仕様で定義されるアルゴリズムは理解しやすいことを意図しており、 高性能であることを意図していません。¶

2.2. 構文表記

この仕様は、 [RFC5234] の Augmented Backus-Naur Form（ABNF）表記を使用します。¶

以下のコアルールは、[RFC5234] の Appendix B.1 で定義されるものとして、 参照により含まれます：ALPHA（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTLs （制御文字）、DIGIT（10進数 0-9）、DQUOTE（二重引用符）、HEXDIG （16進数 0-9/A-F/a-f）、LF（ラインフィード）、NUL（null オクテット）、OCTET（NUL を除く任意の 8 ビットデータ列）、SP（空白）、HTAB（水平タブ）、 CHAR（任意の [USASCII] 文字）、VCHAR（任意の 可視 [USASCII] 文字）、 および WSP（空白類）です。¶

OWS（任意の空白）および BWS（不正な空白）ルールは、 [HTTP] の Section 5.6.3 で定義されます。¶

2.3. 用語

"user agent"、"client"、"server"、"proxy"、および "origin server" という用語は、 HTTP/1.1 仕様（[HTTP] の Section 3）における意味と 同じ意味を持ちます。¶

request-host は、ユーザーエージェントが HTTP リクエストを送信する先、 または HTTP レスポンスを受信する元（すなわち、対応する HTTP リクエストを送信した先）の ホストの名前として、ユーザーエージェントが認識しているものです。¶

request-uri という用語は、 [HTTP] の Section 7.1 で定義される "target URI" を指します。¶

2 つのオクテット列は、 [RFC4790] で定義される i;ascii-casemap 照合順序の下で等価である場合に限り、 互いに大文字小文字を区別せず一致するといいます。¶

string という用語は、NUL でないオクテットの列を意味します。¶

"active browsing context"、"active document"、"ancestor navigables"、 "container document"、"content navigable"、"dedicated worker"、"Document"、 "inclusive ancestor navigables"、"navigable"、"navigate"、"opaque origin"、 "sandboxed origin browsing context flag"、"shared worker"、"the worker's Documents"、"top-level traversable"、および "WorkerGlobalScope" という用語は、 [HTML] で定義されます。¶

"Service Workers" は Service Workers 仕様 [SERVICE-WORKERS] で定義されます。¶

"origin" という用語、URI から origin を導出する機構、および origin に対する "the same" 照合アルゴリズムは、[RFC6454] で定義されます。¶

"Safe" HTTP メソッドには、GET、HEAD、 OPTIONS、および TRACE が含まれ、 [HTTP] の Section 9.2.1 で定義されます。¶

ドメインの "public suffix" は、"com"、"co.uk"、"pvt.k12.wy.us" など、 公的なレジストリによって管理されるドメインの部分です。ドメインの "registrable domain" は、そのドメインの public suffix に、その左側のラベルを加えたものです。 つまり、https://www.site.example では、public suffix は example であり、 registrable domain は site.example です。セキュリティに関する考慮事項については Section 8.9 を参照してください。¶

"request" という用語、および request の "client"、"current url"、"method"、 "target browsing context"、および "url list" は、 [FETCH] で定義されます。¶

"non-HTTP APIs" という用語は、Cookie を設定および取得するために使用される 非 HTTP 機構を指します。たとえば、Cookie をスクリプトに公開する Web ブラウザー API などです。¶

"top-level navigation" という用語は、top-level traversable のナビゲーションを指します。¶

2.4. 名前解決システム

この文書は Cookie で使用する特定の名前解決システムを厳密に規定しませんが、 そのシステムが [USASCII] 文字のみを 使用するか、ASCII 互換エンコーディング（ACE）を使用することを要求します。 Domain Name System（DNS）は典型的かつ従来からの例であるため、この文書では 名前解決を DNS の観点で参照します。¶

Unicode など、非 ASCII 文字を直接公開する名前解決システムは、 この文書の範囲外です。¶

3.1. 例

Set-Cookie ヘッダーフィールドを使用すると、サーバーは HTTP レスポンス内で ユーザーエージェントに短い文字列を送信でき、ユーザーエージェントは Cookie のスコープ内にある 将来の HTTP リクエストでそれを返します。たとえば、サーバーは値 31d4d96e407aad42 を持つ SID という名前の「セッション識別子」をユーザーエージェントに送信できます。 その後、ユーザーエージェントは以降のリクエストでそのセッション識別子を返します。¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

サーバーは Path 属性および Domain 属性を使用して、Cookie のデフォルトスコープを変更できます。 たとえば、サーバーはユーザーエージェントに対し、site.example のすべてのパスおよび すべてのサブドメインへ Cookie を返すよう指示できます。¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

次の例に示すように、サーバーはユーザーエージェントに複数の Cookie を保存できます。 たとえば、サーバーは 2 つの Set-Cookie ヘッダーフィールドを返すことで、 セッション識別子とユーザーの優先言語を保存できます。より機微なセッション識別子に対して 追加のセキュリティ保護を提供するために、サーバーが Secure 属性と HttpOnly 属性を 使用していることに注意してください（Section 4.1.2 参照）。¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=site.example

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

上記の Cookie ヘッダーフィールドには、SID という名前の Cookie と lang という名前の Cookie の 2 つが含まれていることに注意してください。¶

Cookie 名は大文字小文字を区別します。つまり、サーバーがユーザーエージェントに対し、 名前の大文字小文字だけが異なる 2 つの Set-Cookie ヘッダーフィールドを送信した場合、 ユーザーエージェントはそれら両方の Cookie を保存し、以降のリクエストで返します。¶

== Server -> User Agent ==

Set-Cookie: SID=31d4d96e407aad42
Set-Cookie: sid=31d4d96e407aad42

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42

サーバーがユーザーエージェントに Cookie を複数の「セッション」 （たとえばユーザーエージェントの再起動）をまたいで永続化してほしい場合、 サーバーは Expires 属性で有効期限を指定できます。ユーザーエージェントの Cookie ストアが クォータを超えた場合、またはユーザーが手動でサーバーの Cookie を削除した場合、 ユーザーエージェントは有効期限より前に Cookie を削除する可能性があることに注意してください。¶

== Server -> User Agent ==

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2026 10:18:14 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

最後に、Cookie を削除するには、サーバーは過去の有効期限を持つ Set-Cookie ヘッダーフィールドを返します。Cookie の削除が成功するのは、 Set-Cookie ヘッダーフィールド内の Path 属性および Domain 属性が、 Cookie 作成時に使用された値と一致する場合に限られます。¶

== Server -> User Agent ==

Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

== User Agent -> Server ==

Cookie: SID=31d4d96e407aad42

3.2. どの要件を実装するか

次の 2 つの節、Section 4 と Section 5 は、 2 つの異なる種類の実装に対する要件の集合について説明します。この節は、 実装者が自分たちの目的に最も適した要件の集合を判断するための手引きとなることを 意図しています。誤った要件の集合を選択すると、他の Cookie 実装との 互換性が失われる可能性があります。¶

互換性があることの意味は、実装者の目的によって異なることに注意することが重要です。 これらの違いは、意図的および非意図的な仕様変更、仕様解釈、 ならびに歴史的な実装差異により、時間をかけて蓄積されてきました。¶

この節では、Cookie 仕様の実装者を大まかに producer と consumer の 2 種類に分けます。 これらは公式な用語ではなく、読者がユースケースを直感的に理解するのを助けるために ここでのみ使用されます。¶

4.1. Set-Cookie ヘッダー

Set-Cookie HTTP レスポンスヘッダーフィールドは、 サーバーからユーザーエージェントへ Cookie を送信するために使用されます。¶

set-cookie        = set-cookie-string
set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
cookie-pair       = cookie-name BWS "=" BWS cookie-value
cookie-name       = token
cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                      ; US-ASCII characters excluding CTLs,
                      ; whitespace, DQUOTE, comma, semicolon,
                      ; and backslash
token             = <token, defined in [HTTP], Section 5.6.2>

cookie-av         = expires-av / max-age-av / domain-av /
                    path-av / secure-av / httponly-av /
                    samesite-av / extension-av
expires-av        = "Expires" BWS "=" BWS sane-cookie-date
sane-cookie-date  =
    <IMF-fixdate, defined in [HTTP], Section 5.6.7>
max-age-av        = "Max-Age" BWS "=" BWS 1*DIGIT
domain-av         = "Domain" BWS "=" BWS domain-value
domain-value      = <subdomain>
                      ; see details below
path-av           = "Path" BWS "=" BWS path-value
path-value        = *av-octet
secure-av         = "Secure"
httponly-av       = "HttpOnly"
samesite-av       = "SameSite" BWS "=" BWS samesite-value
samesite-value    = "Strict" / "Lax" / "None"
extension-av      = 1*av-octet
av-octet          = %x20-3A / %x3C-7E
                      ; any CHAR except CTLs or ";"

Set-Cookie: __Secure-SID=12345; Domain=site.example

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

Set-Cookie: __Host-SID=12345
Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

Set-Cookie: __Host-SID=12345; Secure; Path=/

4.2. Cookie ヘッダー

cookie        = cookie-string
cookie-string = cookie-pair *( ";" SP cookie-pair )

5.1. サブコンポーネント アルゴリズム

この節は、ユーザーエージェントが Cookie および Set-Cookie ヘッダーフィールドの特定のサブコンポーネントを処理するために使用する いくつかのアルゴリズムを定義します。¶

5.2. "Same-site" および "cross-site" リクエスト

2 つの origin は、[SAMESITE] で定義される "same site" 基準を満たす場合、same-site です。リクエストは、 以下の基準が真である場合に "same-site" です。¶

1. そのリクエストが、ユーザーインターフェイス要素を通じて トリガーされた再読み込みナビゲーションの結果ではないこと （ユーザーエージェントによって定義される。例：ユーザーがツールバーの 更新ボタンをクリックしたことによってトリガーされるリクエスト）。¶

2. request の current url の origin が、request の client の "site for cookies"（origin）と same-site であること、または request が client を持たないか、request の client が null であること。¶

ユーザーインターフェイス要素を通じてトリガーされた 再読み込みナビゲーションの結果であるリクエストは、再読み込みされた文書が もともと same-site リクエストによってナビゲートされたものである場合、same-site です。 "same-site" ではないリクエストは、代わりに "cross-site" です。¶

request の client の "site for cookies" は、 以下の小節で説明するように、その client の種類に応じて計算されます。¶

5.3. Set-Cookie ヘッダーフィールドの無視

ユーザーエージェントは、100 番台のステータスコードを持つ レスポンスに含まれる Set-Cookie ヘッダーフィールドを無視してもよく、 または自らの Cookie ポリシーに基づいて無視してもかまいません （Section 7.2 参照）。¶

その他すべての Set-Cookie ヘッダーフィールドは、Section 5.6 に従って処理されるべきです。 すなわち、100 番台以外のステータスコードを持つレスポンス （400 番台および 500 番台のステータスコードを持つレスポンスを含む）に含まれる Set-Cookie ヘッダーフィールドは、ユーザーエージェントの Cookie ポリシーに従って 無視される場合を除き、処理されるべきです。¶

5.4. Cookie 名接頭辞

Cookie 名接頭辞に関するユーザーエージェントの要件は、 UA が接頭辞文字列を大文字小文字を区別せず一致させなければならない点で、 サーバーの要件（Section 4.1.3）と わずかに異なります。¶

接頭辞に関する規範的要件は、Section 5.7 で 定義される保存モデルアルゴリズムで詳述されます。¶

これは、一部のサーバーが Cookie を大文字小文字を区別せず処理するため、 意図せず接頭辞の大文字小文字を誤って使用し、その誤った大文字小文字の接頭辞を 受け入れてしまうためです。¶

たとえば、サーバーが以下の Set-Cookie ヘッダーフィールドを 送信した場合、¶

Set-Cookie: __SECURE-SID=12345

接頭辞を大文字小文字を区別して確認する UA はこの Cookie を受け入れ、 サーバーはその Cookie が __Secure- と綴られた Cookie と同じ保証の対象であると 誤って信じることになります。¶

さらに、サーバーは、接頭辞付き Cookie になりすますために 攻撃者が意図的に Cookie の大文字小文字を誤って使用する攻撃に対して脆弱です。 たとえば、あるサイトがすでに __Secure-SID=12345 という Cookie を持っており、 攻撃者が何らかの手段で、そのサイトについて以下の Set-Cookie ヘッダーフィールドを、接頭辞を大文字小文字を区別して確認する UA に送信したとします。¶

Set-Cookie: __SeCuRe-SID=evil

次にユーザーがそのサイトを訪問すると、UA は両方の Cookie を送信します。¶

Cookie: __Secure-SID=12345; __SeCuRe-SID=evil

大文字小文字を区別しないサーバーは、この 2 つの Cookie を区別できず、 攻撃者がサイトを侵害できるようになります。¶

これらの問題を防ぐため、UA は Cookie 名接頭辞を 大文字小文字を区別せず一致させなければなりません。¶

注記：名前が異なる Cookie は、UA では依然として別個のものと見なされます。 したがって、__Secure-foo=bar と __secure-foo=baz の両方が、 別個の Cookie として同時に存在でき、どちらにも __Secure- 接頭辞の 要件が適用されます。¶

以下は、適合するユーザーエージェントによって拒否される Set-Cookie ヘッダーフィールドの例です。¶

Set-Cookie: __Secure-SID=12345; Domain=site.example
Set-Cookie: __secure-SID=12345; Domain=site.example
Set-Cookie: __SECURE-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345
Set-Cookie: __host-SID=12345; Secure
Set-Cookie: __host-SID=12345; Domain=site.example
Set-Cookie: __HOST-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Domain=site.example; Path=/

一方、以下の Set-Cookie ヘッダーフィールドは、 secure origin から設定された場合に受け入れられます。¶

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure
Set-Cookie: __Host-SID=12345; Secure; Path=/
Set-Cookie: __host-SID=12345; Secure; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Path=/

5.5. Cookie 有効期間の制限

Expires 属性または Max-Age 属性によって有効期間が指定された Cookie を処理する場合、ユーザーエージェントは Cookie の最大寿命を 制限しなければなりません。この制限は、将来 400 日（34560000 秒）より 大きくするべきではありません。推奨される制限は将来 400 日ですが、 ユーザーエージェントはその制限を調整してもかまいません （Section 7.2 参照）。 制限より長い有効期間を指定する Expires 属性または Max-Age 属性は、 その制限まで短縮されなければなりません。¶

5.6. Set-Cookie ヘッダーフィールド

ユーザーエージェントが HTTP レスポンス内で Set-Cookie ヘッダーフィールドを受信した場合、ユーザーエージェントは Set-Cookie ヘッダーフィールド全体を無視してもかまいません （Section 5.3 参照）。¶

ユーザーエージェントが Set-Cookie ヘッダーフィールド全体を無視しない場合、 ユーザーエージェントは Set-Cookie ヘッダーフィールドの field-value を set-cookie-string（以下で定義）として解析しなければなりません。¶

注記：以下のアルゴリズムは、Section 4.1 の文法よりも寛容です。 たとえば、このアルゴリズムは cookie-name が Section 4.1 で指定される token ではなく cookie-octets で構成されることを許容し、また Section 4.1 の 文法によれば cookie-octets ではないいくつかの文字にも対応します。さらに、 以下のアルゴリズムは Cookie 名と値から先頭および末尾の空白も取り除きます （ただし内部の空白は維持します）が、Section 4.1 の文法はこれらの位置の空白を 禁止しています。ユーザーエージェントは、Section 4 の推奨事項に従わないサーバーと 相互運用するために、このアルゴリズムを使用します。¶

注記：set-cookie-string は non-HTTP API に由来する可能性があるため、 CTL 文字を含まないことは保証されません。したがって、このアルゴリズムは それらを明示的に扱います。水平タブ（%x09）は、set-cookie-string の拒否につながる CTL 文字から除外されます。これは空白と見なされ、別途処理されるためです。¶

注記：set-cookie-string は、 Section 2.1 of [RFC3986] に従って percent-encoded されているように見える オクテット列を含むことがあります。しかし、ユーザーエージェントはこれらの列を デコードしてはならず、代わりにこのアルゴリズムで指定されるとおりに個々のオクテットを 解析しなければなりません。¶

ユーザーエージェントは、set-cookie-string を解析するために、 以下のアルゴリズムと等価なアルゴリズムを使用しなければなりません。¶

1. set-cookie-string が %x00-08 / %x0A-1F / %x7F 文字 （HTAB を除く CTL 文字）を含む場合、 このアルゴリズムを中止し、set-cookie-string 全体を無視します。¶

2. set-cookie-string が %x3B（";"）文字を含む場合、¶

   1. name-value-pair 文字列は、 最初の %x3B（";"）まで（ただしそれを含まない）の文字からなり、 unparsed-attributes は set-cookie-string の残り （問題の %x3B（";"）を含む）からなります。¶

   それ以外の場合、¶

   1. name-value-pair 文字列は、 set-cookie-string に含まれるすべての文字からなり、 unparsed-attributes は空文字列です。¶

3. name-value-pair 文字列に %x3D（"="）文字がない場合、 name 文字列は空であり、value 文字列は name-value-pair の値です。¶

   それ以外の場合、（空である可能性のある）name 文字列は、 最初の %x3D（"="）文字まで（ただしそれを含まない）の文字からなり、 （空である可能性のある）value 文字列は、最初の %x3D（"="）文字の後の 文字からなります。¶

4. name 文字列および value 文字列から、 先頭および末尾の WSP 文字をすべて削除します。¶

5. name 文字列と value 文字列の長さの合計が 4096 オクテットを超える場合、このアルゴリズムを中止し、 set-cookie-string 全体を無視します。¶

6. cookie-name を name 文字列とし、 cookie-value を value 文字列とします。¶

ユーザーエージェントは、unparsed-attributes を解析するために、 以下のアルゴリズムと等価なアルゴリズムを使用しなければなりません。¶

1. unparsed-attributes 文字列が空である場合、 これらのステップの残りをスキップします。¶

2. unparsed-attributes の最初の文字 （%x3B（";"）文字であるはずです）を破棄します。¶

3. 残りの unparsed-attributes が %x3B（";"）文字を含む場合、¶

   1. unparsed-attributes の文字を、 最初の %x3B（";"）文字まで（ただしそれを含まない）消費します。¶

   それ以外の場合、¶

   1. unparsed-attributes の残りを消費します。¶

   cookie-av 文字列を、このステップで消費された文字とします。 unparsed-attributes は、ここで残りの文字を含むようになります。¶

4. cookie-av 文字列が %x3D（"="）文字を含む場合、¶

   1. （空である可能性のある）attribute-name 文字列は、 最初の %x3D（"="）文字まで（ただしそれを含まない）の文字からなり、 （空である可能性のある）attribute-value 文字列は、 最初の %x3D（"="）文字の後の文字からなります。¶

   それ以外の場合、¶

   1. attribute-name 文字列は cookie-av 文字列全体からなり、 attribute-value 文字列は空です。¶

5. attribute-name 文字列および attribute-value 文字列から、 先頭および末尾の WSP 文字をすべて削除します。¶

6. attribute-value が 1024 オクテットを超える場合、 cookie-av 文字列を無視し、このアルゴリズムのステップ 1 に戻ります。¶

7. 以下の小節の要件に従って、 attribute-name および attribute-value を処理します。 （認識されない attribute-name を持つ属性は無視されることに注意してください。）¶

8. このアルゴリズムのステップ 1 に戻ります。¶

ユーザーエージェントが set-cookie-string の解析を完了したとき、 ユーザーエージェントは、request-uri から、名前 cookie-name、値 cookie-value、 属性 cookie-attribute-list を持つ Cookie を「受信する」といいます。 （Cookie の受信によって発生する追加要件については Section 5.7 を参照してください。）¶

 * The HTTP request associated with the retrieval uses a "safe"
   method.

 * At least one of the following is true:

   1.  The HTTP request associated with the retrieval uses a "safe"
       method.

   2.  The cookie's same-site-flag is "Default" and the amount of
       time elapsed since the cookie's creation-time is at most a
       duration of the user agent's choosing.

5.7. 保存モデル

ユーザーエージェントは、各 Cookie について次のフィールドを保存します：name、value、 expiry-time、domain、path、creation-time、last-access-time、 persistent-flag、host-only-flag、secure-only-flag、http-only-flag、 および same-site-flag。¶

ユーザーエージェントが、request-uri から、名前 cookie-name、値 cookie-value、および属性 cookie-attribute-list を持つ Cookie を 「受信する」とき、ユーザーエージェントはその Cookie を次のように処理しなければなりません。¶

1. ユーザーエージェントは、受信した Cookie 全体を無視してもかまいません。 Section 5.3 を参照してください。¶

2. cookie-name が空で、かつ cookie-value も空である場合、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

3. cookie-name または cookie-value が %x00-08 / %x0A-1F / %x7F 文字（HTAB を除く CTL 文字）を含む場合、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

4. cookie-name と cookie-value の長さの合計が 4096 オクテットを超える場合、このアルゴリズムを中止し、その Cookie 全体を無視します。¶

5. name が cookie-name、value が cookie-value である新しい Cookie を作成します。 creation-time と last-access-time を現在の日付と時刻に設定します。¶

6. cookie-attribute-list が attribute-name "Max-Age" を持つ属性を含む場合、¶

   1. Cookie の persistent-flag を true に設定します。¶

   2. Cookie の expiry-time を、cookie-attribute-list 内で attribute-name が "Max-Age" である最後の属性の attribute-value に設定します。¶

   それ以外で、cookie-attribute-list が attribute-name "Expires" を持つ属性を含み （かつ attribute-name "Max-Age" を持つ属性を含まない）場合、¶

   1. Cookie の persistent-flag を true に設定します。¶

   2. Cookie の expiry-time を、cookie-attribute-list 内で attribute-name が "Expires" である最後の属性の attribute-value に設定します。¶

   それ以外の場合、¶

   1. Cookie の persistent-flag を false に設定します。¶

   2. Cookie の expiry-time を表現可能な最新の日付に設定します。¶

7. cookie-attribute-list が attribute-name "Domain" を持つ属性を含む場合、¶

   1. domain-attribute を、cookie-attribute-list 内で attribute-name が "Domain" であり、かつ attribute-value の 長さが 1024 オクテット以下である最後の属性の attribute-value とします。 （先頭の %x2E（"."）が存在する場合、その文字は許可されていないにもかかわらず 無視されることに注意してください。）¶

   それ以外の場合、¶

   1. domain-attribute を空文字列とします。¶

8. domain-attribute が CHAR に含まれない文字を含む場合、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

9. ユーザーエージェントが "public suffixes" を拒否するよう構成されており、 domain-attribute が public suffix である場合、¶

   1. request-host-canonical を正規化された request-host とします。¶

   2. request-host の正規化に失敗した場合、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

   3. domain-attribute が request-host-canonical と同一である場合、¶

      1. domain-attribute を空文字列とします。¶

      それ以外の場合、¶

      1. このアルゴリズムを中止し、その Cookie 全体を無視します。¶

   注記：このステップは、attacker.example が Domain 属性 "example" を持つ Cookie を設定することで site.example の完全性を損なうことを防ぎます。¶

10. domain-attribute が空でない場合、¶

    1. request-host-canonical が domain-attribute に domain-match（Section 5.1.3 参照）しない場合、¶

       1. このアルゴリズムを中止し、 その Cookie 全体を無視します。¶

       それ以外の場合、¶

       1. Cookie の host-only-flag を false に設定します。¶

       2. Cookie の domain を domain-attribute に設定します。¶

    それ以外の場合、¶

    1. Cookie の host-only-flag を true に設定します。¶

    2. Cookie の domain を request-host-canonical に設定します。¶

11. cookie-attribute-list が attribute-name "Path" を持つ属性を含む場合、 Cookie の path を、cookie-attribute-list 内で attribute-name が "Path" であり、 かつ attribute-value の長さが 1024 オクテット以下である最後の属性の attribute-value に設定します。それ以外の場合、Cookie の path を request-uri の default-path に設定します。¶

12. cookie-attribute-list が attribute-name "Secure" を持つ属性を含む場合、 Cookie の secure-only-flag を true に設定します。 それ以外の場合、Cookie の secure-only-flag を false に設定します。¶

13. request-uri が（ユーザーエージェントによって定義される） "secure" 接続を表さず、かつ Cookie の secure-only-flag が true である場合、 これらのステップを中止し、その Cookie 全体を無視します。¶

14. cookie-attribute-list が attribute-name "HttpOnly" を持つ属性を含む場合、 Cookie の http-only-flag を true に設定します。 それ以外の場合、Cookie の http-only-flag を false に設定します。¶

15. Cookie が "non-HTTP" API から受信され、かつ Cookie の http-only-flag が true である場合、このアルゴリズムを中止し、その Cookie 全体を無視します。¶

16. Cookie の secure-only-flag が false であり、request-uri が "secure" 接続を表さない場合、Cookie ストアが以下の基準をすべて満たす 1 つ以上の Cookie を含むなら、このアルゴリズムを中止し、その Cookie 全体を無視します。¶

    1. それらの name が新しく作成された Cookie の name と一致する。¶

    2. それらの secure-only-flag が true である。¶

    3. それらの domain が、新しく作成された Cookie の domain に domain-match（Section 5.1.3 参照）するか、 またはその逆である。¶

    4. 新しく作成された Cookie の path が、 既存の Cookie の path に path-match する。¶

    注記：パス比較は対称ではなく、新しく作成された非 secure Cookie が 既存の secure Cookie を上書きしないことだけを保証し、 cookie-fixing 攻撃に対する一定の軽減を提供します。つまり、 path が '/login' である 'a' という名前の既存の secure Cookie がある場合、 'a' という名前の非 secure Cookie は '/' または '/foo' の path に対して設定できますが、 '/login' または '/login/en' の path に対しては設定できません。¶

17. cookie-attribute-list が attribute-name "SameSite" と、 "Strict"、"Lax"、または "None" の attribute-value を持つ属性を含む場合、 Cookie の same-site-flag を、cookie-attribute-list 内で attribute-name が "SameSite" である 最後の属性の attribute-value に設定します。それ以外の場合、Cookie の same-site-flag を "Default" に設定します。¶

18. Cookie の same-site-flag が "None" でない場合、¶

    1. Cookie が "non-HTTP" API から受信され、 その API が、"site for cookies" が top-level origin と same-site でない navigable の active document から呼び出された場合、 このアルゴリズムを中止し、新しく作成された Cookie 全体を無視します。¶

    2. Cookie が（Section 5.2 で定義される） "same-site" リクエストから受信された場合、残りのサブステップをスキップして、 Cookie の処理を続行します。¶

    3. Cookie が top-level traversable [HTML] をナビゲートしているリクエストから受信された場合 （たとえば、リクエストの "reserved client" が null、または "target browsing context" の navigable が top-level traversable である環境のいずれかである場合）、 残りのサブステップをスキップして、Cookie の処理を続行します。¶

       注記：Top-level navigation は、たとえ新しい Cookie がそのナビゲーションの前に すでに存在していたとしても、そのリクエストとともに送信されなかったような場合であっても、 任意の SameSite 値を持つ Cookie を作成できます。¶

    4. このアルゴリズムを中止し、 新しく作成された Cookie 全体を無視します。¶

19. Cookie の "same-site-flag" が "None" である場合、 Cookie の secure-only-flag が true でない限り、このアルゴリズムを中止し、 その Cookie 全体を無視します。¶

20. cookie-name が文字列 "__Secure-" と大文字小文字を区別せずに一致するもので 始まる場合、Cookie の secure-only-flag が true でない限り、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

21. cookie-name が文字列 "__Host-" と大文字小文字を区別せずに一致するもので 始まる場合、Cookie が以下の基準をすべて満たさない限り、 このアルゴリズムを中止し、その Cookie 全体を無視します。¶

    1. Cookie の secure-only-flag が true である。¶

    2. Cookie の host-only-flag が true である。¶

    3. cookie-attribute-list が attribute-name "Path" を持つ属性を含み、Cookie の path が / である。¶

22. cookie-name が空であり、かつ次のいずれかの条件が true である場合、このアルゴリズムを中止し、その Cookie 全体を無視します。¶

    • cookie-value が文字列 "__Secure-" と 大文字小文字を区別せずに一致するもので始まる¶

    • cookie-value が文字列 "__Host-" と 大文字小文字を区別せずに一致するもので始まる¶

23. Cookie ストアが、新しく作成された Cookie と同じ name、domain、 host-only-flag、および path を持つ Cookie を含む場合、¶

    1. old-cookie を、新しく作成された Cookie と同じ name、domain、host-only-flag、および path を持つ既存の Cookie とします。 （このアルゴリズムは、そのような Cookie が最大 1 つしか存在しないという 不変条件を維持することに注意してください。）¶

    2. 新しく作成された Cookie が "non-HTTP" API から受信され、 old-cookie の http-only-flag が true である場合、このアルゴリズムを中止し、 新しく作成された Cookie 全体を無視します。¶

    3. 新しく作成された Cookie の creation-time を、 old-cookie の creation-time と一致するように更新します。¶

    4. old-cookie を Cookie ストアから削除します。¶

24. 新しく作成された Cookie を Cookie ストアに挿入します。¶

Cookie の expiry date が過去である場合、その Cookie は「期限切れ」です。¶

Cookie ストア内に期限切れの Cookie が存在する場合、ユーザーエージェントは いつでも Cookie ストアからすべての期限切れ Cookie を削除しなければなりません。¶

ある domain フィールドを共有する Cookie の数が、何らかの 実装定義の上限（たとえば 50 個の Cookie）を超える場合、ユーザーエージェントは いつでも Cookie ストアから「過剰な Cookie を削除」してもかまいません。¶

Cookie ストアが何らかの所定の上限（たとえば 3000 個の Cookie）を超える場合、ユーザーエージェントはいつでも Cookie ストアから 「過剰な Cookie を削除」してもかまいません。¶

ユーザーエージェントが Cookie ストアから過剰な Cookie を削除する場合、 ユーザーエージェントは次の優先順位で Cookie を削除しなければなりません。¶

1. 期限切れの Cookie。¶

2. secure-only-flag が false であり、かつ所定の数より多い 他の Cookie と domain フィールドを共有する Cookie。¶

3. 所定の数より多い他の Cookie と domain フィールドを 共有する Cookie。¶

4. すべての Cookie。¶

2 つの Cookie が同じ削除優先度を持つ場合、 ユーザーエージェントは last-access-time が最も早い Cookie から先に削除しなければなりません。¶

「現在のセッションが終了したとき」（ユーザーエージェントによって定義）、 ユーザーエージェントは persistent-flag が false に設定されたすべての Cookie を Cookie ストアから削除しなければなりません。¶

5.8. 取得モデル

この節は、Cookie ストアから Cookie を cookie-string の形で取得する方法を 定義します。「取得」とは、cookie-string の生成を必要とする任意のイベントです。 たとえば、取得は HTTP リクエスト用の Cookie ヘッダーフィールドを構築するために 発生することもあれば、Cookie へのアクセスを提供する "non-HTTP" API の呼び出しから cookie-string を返すために必要になることもあります。取得には関連付けられた URI、 same-site status、および type があり、それらは取得の種類に応じて以下で定義されます。¶

6.1. 制限

実用的なユーザーエージェント実装には、保存できる Cookie の数とサイズに 制限があります。汎用のユーザーエージェントは、次の各最小能力を提供するべきです。¶

• ドメインごとに少なくとも 50 個の Cookie。¶

• 合計で少なくとも 3000 個の Cookie。¶

ユーザーエージェントは、保存する Cookie の最大数を制限してもよく、 （ユーザーの要求によるか、実装上の制限によるかにかかわらず） 任意の Cookie をいつでも削除してもかまいません。¶

Cookie の最大数に対する制限は、Section 5.6 で 強制されなければならない長さ制限により、保存される Cookie の総サイズも 制限することに注意してください。¶

サーバーは、これらの実装制限に達することを避け、 Cookie ヘッダーフィールドがすべてのリクエストに含まれることによる ネットワーク帯域幅を最小化し、サーバーのヘッダーフィールド制限に達することを 避けるために（Section 4.2.1 を参照）、可能な限り少数かつ小さな Cookie を使用するべきです。¶

ユーザーエージェントは任意の Cookie をいつでも削除し得るため、 ユーザーエージェントが Cookie ヘッダーフィールドで 1 つ以上の Cookie を返さなかった場合、 サーバーは段階的に機能低下するべきです。¶

6.2. アプリケーション プログラミングインターフェイス

Cookie および Set-Cookie ヘッダーフィールドがこれほど難解な扱いを 使用する理由の 1 つは、多くのプラットフォーム（サーバーとユーザーエージェントの両方）が Cookie に対して文字列ベースのアプリケーションプログラミングインターフェイス（API）を 提供しており、アプリケーション層のプログラマーが Cookie および Set-Cookie ヘッダーフィールドで使用される構文を生成および解析する必要があるためです。 多くのプログラマーはこれを誤って行い、相互運用性の問題を引き起こしてきました。¶

Cookie に対して文字列ベースの API を提供する代わりに、 プラットフォームはより意味論的な API を提供することで恩恵を受けます。 具体的な API 設計を推奨することはこの文書の範囲外ですが、 直列化された日付文字列ではなく抽象的な "Date" オブジェクトを受け入れることには 明確な利点があります。¶

7.1. サードパーティ Cookie

"third-party" または cross-site Cookie とは、主要リソース （通常はユーザーが閲覧している Web ページ）をホストするサーバーとは異なるサーバーから取得される、 埋め込みコンテンツ（スクリプト、画像、スタイルシート、フレームなど）に関連付けられた Cookie です。 サードパーティ Cookie は、異なるサイト上のユーザー活動を関連付けるためによく使用されます。¶

サードパーティ Cookie には本質的なプライバシー問題があるため、 現在ほとんどのユーザーエージェントはさまざまな方法でサードパーティ Cookie を制限しています。 一部は、サードパーティ Set-Cookie ヘッダーフィールドの処理を拒否し、サードパーティ Cookie ヘッダーフィールドの送信を拒否することで、サードパーティ Cookie を完全にブロックします。 一部は、first-party context に基づいて Cookie をパーティション化し、閲覧されているサイトに応じて 異なる Cookie が送信されるようにします。一部は、ユーザーエージェントの Cookie ポリシーおよび/または ユーザー制御に基づいて Cookie をブロックします。¶

この文書は特定のアプローチを支持または要求するものではありませんが、 ユーザーエージェントは、互換性上の制約が許す限り制限的なサードパーティ Cookie のポリシーを 採用することが推奨されます。したがって、リソースは、予見可能な将来にわたって サードパーティ Cookie がユーザーエージェントによって一貫して扱われることに依存できません。¶

7.2. Cookie ポリシー

ユーザーエージェントは、Cookie をどのように使用または無視できるかに関する 制限からなる Cookie ポリシーを強制してもかまいません （Section 5.3 参照）。¶

Cookie ポリシーは、ユーザーエージェントが Cookie アクセスを許可する ドメインまたはパーティ、たとえば first party と third party （Section 7.1 参照）を 規定することがあります。このポリシーは、Cookie サイズ、Cookie の有効期限 （Section 5.5 参照）、 およびドメインごとまたは合計の Cookie 数に関する制限も定義できます。¶

推奨される Cookie 有効期限の上限は 400 日です。 ユーザーエージェントは、より短いデータ保持期間を強制するためにより低い制限を設定してもよく、 適切な場合（たとえば HTTPS 上の server-to-server 通信）には、より長い保持をサポートするために 制限をより高く設定してもかまいません。¶

制限的な Cookie ポリシーの目的は、多くの場合、セキュリティまたはプライバシーを 改善することです。ユーザーエージェントはしばしば、ユーザーが Cookie ポリシーを変更できるようにします （Section 7.3 参照）。¶

7.3. ユーザー制御

ユーザーエージェントは、Cookie ストアに保存された Cookie を管理するための 機構をユーザーに提供するべきです。たとえば、ユーザーエージェントは、 指定された期間中に受信したすべての Cookie、または特定のドメインに関連する すべての Cookie をユーザーが削除できるようにしてもよいです。さらに、多くの ユーザーエージェントは、Cookie ストアに保存された Cookie をユーザーが調べられる ユーザーインターフェイス要素を含みます。¶

ユーザーエージェントは、Cookie を無効化するための機構をユーザーに 提供するべきです。Cookie が無効化されている場合、ユーザーエージェントは 送信 HTTP リクエストに Cookie ヘッダーフィールドを含めてはならず、受信 HTTP レスポンス内の Set-Cookie ヘッダーフィールドを処理してはなりません。¶

ユーザーエージェントは、Cookie ポリシーを変更する方法を提供してもかまいません （Section 7.2 参照）。¶

ユーザーエージェントは、セッションをまたいだ Cookie の永続保存を防止する オプションをユーザーに提供してもかまいません。このように構成されている場合、 ユーザーエージェントは、受信したすべての Cookie を persistent-flag が false に 設定されているかのように扱わなければなりません。一部の一般的なユーザーエージェントは、 この機能を "private browsing" モード [Aggarwal2010] として公開しています。¶

7.4. 有効期限

サーバーは Cookie の有効期限を遠い将来に設定できますが、 ほとんどのユーザーエージェントは実際には Cookie を何十年も保持しません。 サーバーは、不必要に長い有効期間を選ぶのではなく、Cookie の目的に基づいて 合理的な Cookie 有効期間を選択することで、ユーザーのプライバシーを促進するべきです。 たとえば、一般的なセッション識別子は、2 週間後に期限切れになるよう設定するのが 合理的である場合があります。¶

8.1. 概要

Cookie には多くのセキュリティ上の落とし穴があります。この節では、 より顕著ないくつかの問題を概説します。¶

特に、Cookie は開発者が認証のために環境権限に依存することを促し、 cross-site request forgery [CSRF] などの攻撃に脆弱になることがよくあります。また、セッション識別子を Cookie に 保存する場合、開発者はしばしばセッション固定の脆弱性を作り出します。¶

HTTPS で用いられるようなトランスポート層暗号化は、Cookie に対する ネットワーク攻撃への重要な防御層を提供します。しかし、Cookie プロトコル自体に内在する 脆弱性のため、ネットワーク攻撃者が被害者の Cookie を取得または変更することを 完全に防止するには不十分です（後述の「弱い機密性」および「弱い完全性」を参照）。 さらに、デフォルトでは、Cookie は HTTPS と併用される場合であっても、ネットワーク攻撃者に 対する機密性や完全性を提供しません。これは、Cookie が保護属性を明示的に 指定する必要があることを意味します。たとえば、次の Cookie は：¶

Set-Cookie: a=b ¶

Secure 属性を指定していないため、それが作成された元の接続タイプに関係なく、 secure な接続と insecure な接続の両方でアクセス可能になります。この挙動により、 攻撃者が Cookie を読み取ったり変更したりできる可能性があります。¶

8.2. 環境権限

Cookie を使用してユーザーを認証するサーバーは、セキュリティ脆弱性を 被る可能性があります。なぜなら、一部のユーザーエージェントは、リモートパーティが ユーザーエージェントから HTTP リクエストを発行できるようにしているためです （たとえば HTTP リダイレクトや HTML フォームを介して）。それらのリクエストを発行する際、 リモートパーティが Cookie の内容を知らない場合でも、ユーザーエージェントは Cookie を付加します。 これにより、リモートパーティが不用意なサーバーで権限を行使できる可能性があります。¶

このセキュリティ上の懸念は多くの名前（たとえば cross-site request forgery、confused deputy）で呼ばれますが、問題は Cookie が 環境権限の一形態であることに由来します。Cookie は、サーバー運用者が 指定（URL の形）と認可（Cookie の形）を分離することを促します。 その結果、ユーザーエージェントは攻撃者によって指定されたリソースに対して 認可を提供し、サーバーまたはそのクライアントが、攻撃者によって指定された操作を ユーザーによって認可されたかのように実行する可能性があります。¶

サーバー運用者は、認可に Cookie を使用する代わりに、URL を ケイパビリティとして扱うことで、指定と認可を結び付けることを検討してもよいです。 このアプローチでは、秘密情報を Cookie に保存する代わりに URL に保存し、 リモートエンティティに秘密情報そのものを提供することを要求します。 このアプローチは万能薬ではありませんが、これらの原則を慎重に適用することで、 より堅牢なセキュリティにつながる可能性があります。¶

8.3. 平文

TLS [TLS13] のような secure チャネル上で送信されない限り、 Cookie および Set-Cookie ヘッダーフィールド内の情報は平文で送信されます。¶

1. これらのヘッダーフィールドで伝達されるすべての機微情報は、 盗聴者に公開されます。¶

2. 悪意ある仲介者は、いずれの方向に流れる場合でも ヘッダーフィールドを変更でき、予測不能な結果をもたらす可能性があります。¶

サーバーは、Cookie をユーザーエージェントへ送信するとき、 （Cookie を secure チャネル上で送信する場合であっても）Cookie の内容を 暗号化し署名するべきです（サーバーが望む任意の形式を使用して）。 ただし、Cookie の内容を暗号化し署名しても、攻撃者が Cookie をあるユーザーエージェントから 別のユーザーエージェントへ移植したり、後で Cookie を再生したりすることは防げません。¶

すべての Cookie の内容を暗号化し署名することに加え、 より高いレベルのセキュリティを必要とするサーバーは、Cookie および Set-Cookie ヘッダーフィールドを secure チャネル上でのみ使用するべきです。secure チャネル上で Cookie を使用する場合、サーバーはすべての Cookie に Secure 属性（Section 4.1.2.5 参照）を設定するべきです。 サーバーが Secure 属性を設定しない場合、secure チャネルによって提供される保護は ほとんど意味を失います。¶

たとえば、セッション識別子を Cookie に保存し、通常 HTTPS 経由で アクセスされる Web メールサーバーを考えてください。サーバーが Cookie に Secure 属性を設定していない場合、能動的なネットワーク攻撃者は、ユーザーエージェントからの 任意の送信 HTTP リクエストを傍受し、そのリクエストを HTTP 経由で Web メールサーバーへ リダイレクトできます。Web メールサーバーが HTTP 接続を待ち受けていない場合でも、 ユーザーエージェントはそのリクエストに Cookie を含めます。能動的なネットワーク攻撃者は これらの Cookie を傍受し、サーバーに対して再生し、ユーザーのメールの内容を知ることが できます。代わりに、サーバーが Cookie に Secure 属性を設定していた場合、 ユーザーエージェントは平文リクエストに Cookie を含めなかったでしょう。¶

8.4. セッション識別子

セッション情報を Cookie に直接保存する代わりに （攻撃者に公開されたり再生されたりする可能性があるため）、 サーバーは一般に nonce（または「セッション識別子」）を Cookie に保存します。 サーバーが nonce を含む HTTP リクエストを受信すると、サーバーは nonce をキーとして Cookie に関連付けられた状態情報を検索できます。¶

セッション識別子 Cookie を使用すると、攻撃者が Cookie の内容を知った場合に 引き起こせる損害を制限できます。これは、nonce がサーバーとのやり取りにのみ有用であるためです （nonce でない Cookie 内容とは異なり、それ自体が機微である可能性があります）。 さらに、単一の nonce を使用すると、攻撃者がサーバーとの 2 つのやり取りから Cookie 内容を「継ぎ合わせる」ことを防ぎ、それによってサーバーが予期しない挙動を する可能性を低減します。¶

セッション識別子の使用にリスクがないわけではありません。たとえば、 サーバーは「セッション固定」脆弱性を避けるよう注意するべきです。 セッション固定攻撃は 3 つのステップで進行します。第一に、攻撃者はセッション識別子を 自分のユーザーエージェントから被害者のユーザーエージェントへ移植します。 第二に、被害者はそのセッション識別子を使用してサーバーとやり取りし、 ユーザーの認証情報または機密情報をセッション識別子に付与する可能性があります。 第三に、攻撃者はそのセッション識別子を使用してサーバーと直接やり取りし、 ユーザーの権限または機密情報を取得する可能性があります。¶

8.5. 弱い機密性

Cookie はポートによる分離を提供しません。あるポートで動作する サービスが Cookie を読み取れる場合、同じサーバーの別のポートで動作するサービスも その Cookie を読み取れます。あるポート上のサービスが Cookie を書き込める場合、 同じサーバーの別のポートで動作するサービスもその Cookie を書き込めます。 このため、サーバーは、同じホストの異なるポートで相互に信頼しないサービスを実行し、 かつセキュリティ上機微な情報を Cookie に保存する、ということを同時に行うべきではありません。¶

Cookie は scheme による分離を提供しません。最も一般的には http および https scheme とともに使用されますが、あるホストの Cookie は ftp や gopher など他の scheme でも利用可能である可能性があります。 scheme による分離の欠如は、Cookie へのアクセスを許可する non-HTTP API （たとえば HTML の document.cookie API）で最も明らかですが、scheme による 分離の欠如は、実際には Cookie 自体を処理する要件にも存在します （たとえば、HTTP 経由で gopher scheme の URI を取得することを考えてください）。¶

Cookie は常にパスによる分離を提供するわけではありません。 ネットワークレベルのプロトコルは、あるパスに保存された Cookie を別のパスに送信しませんが、 一部のユーザーエージェントは HTML の document.cookie API などの non-HTTP API を通じて Cookie を公開します。これらのユーザーエージェントの一部（たとえば Web ブラウザー）は、 異なるパスから受信したリソースを分離しないため、あるパスから取得されたリソースが、 別のパスに保存された Cookie にアクセスできる可能性があります。¶

8.6. 弱い完全性

Cookie は兄弟ドメイン（およびそのサブドメイン）に対する完全性保証を 提供しません。たとえば、foo.site.example と bar.site.example を考えてください。 foo.site.example サーバーは Domain 属性が "site.example" である Cookie を設定でき （bar.site.example によって設定された既存の "site.example" Cookie を上書きする可能性があります）、 ユーザーエージェントはその Cookie を bar.site.example への HTTP リクエストに含めます。 最悪の場合、bar.site.example はこの Cookie を自分自身が設定した Cookie と区別できません。 foo.site.example サーバーは、この能力を利用して bar.site.example に対する攻撃を 仕掛けられる可能性があります。¶

Set-Cookie ヘッダーフィールドは Path 属性をサポートしていますが、 ユーザーエージェントは Set-Cookie ヘッダーフィールド内の任意の Path 属性を 受け入れるため、Path 属性は完全性保護を提供しません。たとえば、 http://site.example/foo/bar へのリクエストに対する HTTP レスポンスは、 Path 属性が "/qux" である Cookie を設定できます。したがって、サーバーは 同じホストの異なるパスで相互に信頼しないサービスを実行し、かつセキュリティ上 機微な情報を Cookie に保存する、ということを同時に行うべきではありません。¶

能動的なネットワーク攻撃者は、http://site.example/ からのレスポンスを 偽装し、Set-Cookie ヘッダーフィールドを注入することで、https://site.example/ へ送信される Cookie ヘッダーフィールドにも Cookie を注入できます。site.example の HTTPS サーバーは、 これらの Cookie を自分自身が HTTPS レスポンスで設定した Cookie と区別できません。 能動的なネットワーク攻撃者は、site.example が HTTPS のみを使用している場合であっても、 この能力を利用して site.example に対する攻撃を仕掛けられる可能性があります。¶

サーバーは、Cookie の内容を暗号化し署名するか、 __Secure- 接頭辞を持つ名前を Cookie に付けることで、 これらの攻撃を部分的に軽減できます。しかし、暗号を使用しても問題を完全には 軽減できません。なぜなら、攻撃者は本物の site.example サーバーから受け取った Cookie を ユーザーのセッション内で再生でき、予測不能な結果をもたらす可能性があるためです。¶

最後に、攻撃者は大量の Cookie を保存することで、 ユーザーエージェントに Cookie を削除させられる可能性があります。 ユーザーエージェントが保存上限に達すると、ユーザーエージェントは一部の Cookie を 削除せざるを得なくなります。サーバーは、ユーザーエージェントが Cookie を保持することに 依存するべきではありません。¶

8.7. DNS への依存

Cookie はセキュリティを Domain Name System（DNS）に依存します。 DNS が部分的または完全に侵害された場合、Cookie プロトコルはアプリケーションが 必要とするセキュリティ特性を提供できなくなる可能性があります。¶

8.8. SameSite Cookie

8.9. Public Suffix List

Cookie の境界はサイトの "registrable domain" に依存し、 それはさらにドメインの public suffix に依存します。¶

可能な場合はいつでも、ユーザーエージェントは Mozilla プロジェクトが [PSL] で維持しているもののような、 最新の public suffix list を使用するべきです。¶

そうしないと、悪意ある Cookie または機微な Cookie が registrable domain 間で漏えいする可能性があります。¶

9.1. Cookie

HTTP Field Name Registry（[HttpFieldNameRegistry] 参照）は、次の登録で 更新される必要があります。¶

ヘッダーフィールド名:

Cookie¶

適用可能なプロトコル:

http¶

ステータス:

standard¶

著者/変更管理者:

IETF¶

仕様文書:

この仕様（Section 5.8.1）¶

9.2. Set-Cookie

HTTP Field Name Registry（[HttpFieldNameRegistry] 参照）は、次の登録で 更新される必要があります。¶

ヘッダーフィールド名:

Set-Cookie¶

適用可能なプロトコル:

http¶

ステータス:

standard¶

著者/変更管理者:

IETF¶

仕様文書:

この仕様（Section 5.6）¶

9.3. "Cookie Attributes" レジストリ

IANA は、Cookie の挙動を制御するために使用される属性の名前空間を定義する "Cookie Attributes" レジストリを作成するよう求められています。このレジストリは、 https://www.iana.org/assignments/cookie-attribute-names にある "Hypertext Transfer Protocol (HTTP) Cookie Attributes" という新しいレジストリグループで 維持されるべきです。¶

10.1. 規範的参考文献

[DOM-DOCUMENT-COOKIE]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML - Living Standard", n.d., <https://html.spec.whatwg.org/#dom-document-cookie>. WHATWG

[HTTP]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>.

[RFC1123]

Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/rfc/rfc1123>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4790]

Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, DOI 10.17487/RFC4790, March 2007, <https://www.rfc-editor.org/rfc/rfc4790>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC6454]

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/rfc/rfc6454>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[SAMESITE]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML Living Standard", n.d., <https://html.spec.whatwg.org/#same-site>. WHATWG

[USASCII]

American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

10.2. 参考情報

[Aggarwal2010]

Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, "An Analysis of Private Browsing Modes in Modern Browsers", 2010, <http://www.usenix.org/events/sec10/tech/full_papers/Aggarwal.pdf>.

[app-isolation]

Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson, "App Isolation - Get the Security of Multiple Browsers with Just One", 2011, <http://www.collinjackson.com/research/papers/appisolation.pdf>.

[CSRF]

Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, ACM CCS '08: Proceedings of the 15th ACM conference on Computer and communications security (pages 75-88), October 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

[FETCH]

van Kesteren, A., "Fetch Living Standard", n.d., <https://fetch.spec.whatwg.org/>. WHATWG

[HTML]

van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., Jägenstedt, P., and S. Pieters, "HTML Living Standard", n.d., <https://html.spec.whatwg.org/>. WHATWG

[HttpFieldNameRegistry]

"Hypertext Transfer Protocol (HTTP) Field Name Registry", n.d., <https://www.iana.org/assignments/http-fields/>.

[prerendering]

Bentzel, C., "Chrome Prerendering", n.d., <https://www.chromium.org/developers/design-documents/prerender>.

[PSL]

"Public Suffix List", n.d., <https://publicsuffix.org/list/>.

[RFC2109]

Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, <https://www.rfc-editor.org/rfc/rfc2109>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC6265]

Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/rfc/rfc6265>.

[RFC7034]

Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-Options", RFC 7034, DOI 10.17487/RFC7034, October 2013, <https://www.rfc-editor.org/rfc/rfc7034>.

[RFC9113]

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/rfc/rfc9113>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

[SERVICE-WORKERS]

Archibald, J. and M. Kruisselbrink, "Service Workers", n.d., <https://www.w3.org/TR/service-workers/>.

[TLS13]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.