draft-ietf-httpbis-rfc6265bis-19.txt   draft-ietf-httpbis-rfc6265bis-latest.txt 
HTTP Working Group S. Bingler, Ed. HTTP Working Group S. Bingler, Ed.
Internet-Draft M. West, Ed. Internet-Draft M. West, Ed.
Obsoletes: 6265 (if approved) Google LLC Obsoletes: 6265 (if approved) Google LLC
Intended status: Standards Track J. Wilander, Ed. Intended status: Standards Track J. Wilander, Ed.
Expires: July 11, 2025 Apple, Inc Expires: August 20, 2025 Apple, Inc
January 7, 2025 February 16, 2025
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-19 draft-ietf-httpbis-rfc6265bis-latest
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 6265. on the Internet. This document obsoletes RFC 6265.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2025. This Internet-Draft will expire on August 20, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Which Requirements to Implement . . . . . . . . . . . . . 9 3.2. Which Requirements to Implement . . . . . . . . . . . . . 10
3.2.1. Cookie Producing Implementations . . . . . . . . . . 10 3.2.1. Cookie Producing Implementations . . . . . . . . . . 10
3.2.2. Cookie Consuming Implementations . . . . . . . . . . 10 3.2.2. Cookie Consuming Implementations . . . . . . . . . . 11
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 16 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 17
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 19 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 19
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 19 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 20
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 21 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 22
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 22 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 22
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 22 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 22
5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 23 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 23
5.2.1. Document-based requests . . . . . . . . . . . . . . . 23 5.2.1. Document-based requests . . . . . . . . . . . . . . . 23
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 24 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 24
5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 25 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 26
5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 25 5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 26
5.5. Cookie Lifetime Limits . . . . . . . . . . . . . . . . . 27 5.5. Cookie Lifetime Limits . . . . . . . . . . . . . . . . . 27
5.6. The Set-Cookie Header Field . . . . . . . . . . . . . . . 27 5.6. The Set-Cookie Header Field . . . . . . . . . . . . . . . 28
5.6.1. The Expires Attribute . . . . . . . . . . . . . . . . 30 5.6.1. The Expires Attribute . . . . . . . . . . . . . . . . 30
5.6.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 30 5.6.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 31
5.6.3. The Domain Attribute . . . . . . . . . . . . . . . . 31 5.6.3. The Domain Attribute . . . . . . . . . . . . . . . . 31
5.6.4. The Path Attribute . . . . . . . . . . . . . . . . . 31 5.6.4. The Path Attribute . . . . . . . . . . . . . . . . . 32
5.6.5. The Secure Attribute . . . . . . . . . . . . . . . . 32 5.6.5. The Secure Attribute . . . . . . . . . . . . . . . . 32
5.6.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32 5.6.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32
5.6.7. The SameSite Attribute . . . . . . . . . . . . . . . 32 5.6.7. The SameSite Attribute . . . . . . . . . . . . . . . 32
5.7. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34 5.7. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34
5.8. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 39 5.8. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 40
5.8.1. The Cookie Header Field . . . . . . . . . . . . . . . 40 5.8.1. The Cookie Header Field . . . . . . . . . . . . . . . 40
5.8.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 40 5.8.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 41
5.8.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 41 5.8.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 41
6. Implementation Considerations . . . . . . . . . . . . . . . . 42 6. Implementation Considerations . . . . . . . . . . . . . . . . 43
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Application Programming Interfaces . . . . . . . . . . . 43 6.2. Application Programming Interfaces . . . . . . . . . . . 44
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 44 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45
7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 46
7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 45 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46
7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 47 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 48
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 48 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 49
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 49 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 49
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 49 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 50
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 50 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 51
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 50 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 51
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 50 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 51
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 51 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 51
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 51 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 52
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 52 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 52
8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 52 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 53
8.8.6. Top-level requests with "unsafe" methods . . . . . . 53 8.8.6. Top-level requests with "unsafe" methods . . . . . . 53
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 54 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 54 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 55
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 57
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 58 Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 59 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header field. return the name/value pairs in the Cookie header field.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
Set-Cookie header fields. The origin server is free to ignore the Set-Cookie header fields. The origin server is free to ignore the
Cookie header field or use its contents for an application-defined Cookie header field or use its contents for an application-defined
purpose. purpose.
Origin servers MAY send a Set-Cookie response header field with any Origin servers MAY send a Set-Cookie response header field with any
response. An origin server can include multiple Set-Cookie header response. An origin server can include multiple Set-Cookie header
fields in a single response. The presence of a Cookie or a Set- fields in a single response. The presence of a Cookie or a Set-
Cookie header field does not preclude HTTP caches from storing and Cookie header field does not preclude HTTP caches from storing and
reusing a response. reusing a response.
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into Origin servers and intermediaries MUST NOT combine multiple Set-
a single header field. The usual mechanism for folding HTTP headers Cookie header fields into a single header field. The usual mechanism
fields (i.e., as defined in Section 5.3 of [HTTP]) might change the for combining HTTP headers fields (i.e., as defined in Section 5.3 of
semantics of the Set-Cookie header field because the %x2C (",") [HTTP]) might change the semantics of the Set-Cookie header field
character is used by Set-Cookie in a way that conflicts with such because the %x2C (",") character is used by Set-Cookie in a way that
folding. conflicts with such combining.
For example,
Set-Cookie: a=b;path=/c,d=e
is ambiguous. It could be intended as two cookies, a=b and d=e, or a
single cookie with a path of /c,d=e.
User agents MAY ignore Set-Cookie header fields based on response User agents MAY ignore Set-Cookie header fields based on response
status codes or the user agent's cookie policy (see Section 5.3). status codes or the user agent's cookie policy (see Section 5.3).
3.1. Examples 3.1. Examples
Using the Set-Cookie header field, a server can send the user agent a Using the Set-Cookie header field, a server can send the user agent a
short string in an HTTP response that the user agent will return in short string in an HTTP response that the user agent will return in
future HTTP requests that are within the scope of the cookie. For future HTTP requests that are within the scope of the cookie. For
example, the server can send the user agent a "session identifier" example, the server can send the user agent a "session identifier"
skipping to change at page 11, line 44 skipping to change at page 12, line 14
4.1. Set-Cookie 4.1. Set-Cookie
The Set-Cookie HTTP response header field is used to send cookies The Set-Cookie HTTP response header field is used to send cookies
from the server to the user agent. from the server to the user agent.
4.1.1. Syntax 4.1.1. Syntax
Informally, the Set-Cookie response header field contains a cookie, Informally, the Set-Cookie response header field contains a cookie,
which begins with a name-value-pair, followed by zero or more which begins with a name-value-pair, followed by zero or more
attribute-value pairs. Servers SHOULD NOT send Set-Cookie header attribute-value pairs. Servers conforming to this profile MUST NOT
fields that fail to conform to the following grammar: send Set-Cookie header fields that deviate from the following
grammar:
set-cookie = set-cookie-string set-cookie = set-cookie-string
set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av ) set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
cookie-pair = cookie-name BWS "=" BWS cookie-value cookie-pair = cookie-name BWS "=" BWS cookie-value
cookie-name = token cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs, ; US-ASCII characters excluding CTLs,
; whitespace, DQUOTE, comma, semicolon, ; whitespace, DQUOTE, comma, semicolon,
; and backslash ; and backslash
skipping to change at page 12, line 42 skipping to change at page 13, line 9
samesite-av = "SameSite" BWS "=" BWS samesite-value samesite-av = "SameSite" BWS "=" BWS samesite-value
samesite-value = "Strict" / "Lax" / "None" samesite-value = "Strict" / "Lax" / "None"
extension-av = *av-octet extension-av = *av-octet
av-octet = %x20-3A / %x3C-7E av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";" ; any CHAR except CTLs or ";"
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
Per the grammar above, servers SHOULD NOT produce nameless cookies Per the grammar above, servers MUST NOT produce nameless cookies
(i.e.: an empty cookie-name) as such cookies may be unpredictably (i.e.: an empty cookie-name) as such cookies may be unpredictably
serialized by UAs when sent back to the server. serialized by UAs when sent back to the server.
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base64 [RFC4648]. example, using Base64 [RFC4648].
Per the grammar above, the cookie-value MAY be wrapped in DQUOTE Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
skipping to change at page 13, line 17 skipping to change at page 13, line 31
characters are not stripped. They are part of the cookie-value, and characters are not stripped. They are part of the cookie-value, and
will be included in Cookie header fields sent to the server. will be included in Cookie header fields sent to the server.
The domain-value is a subdomain as defined by [RFC1034], Section 3.5, The domain-value is a subdomain as defined by [RFC1034], Section 3.5,
and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a
string of [USASCII] characters, such as an "A-label" as defined in string of [USASCII] characters, such as an "A-label" as defined in
Section 2.3.2.1 of [RFC5890]. Section 2.3.2.1 of [RFC5890].
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
servers SHOULD NOT produce two attributes with the same name in the servers MUST NOT produce two attributes with the same name in the
same set-cookie-string. (See Section 5.7 for how user agents handle same set-cookie-string. (See Section 5.7 for how user agents handle
this case.) this case.)
NOTE: The name of an attribute-value pair is not case-sensitive. So NOTE: The name of an attribute-value pair is not case-sensitive. So
while they are presented here in CamelCase, such as "HttpOnly" or while they are presented here in CamelCase, such as "HttpOnly" or
"SameSite", any case is accepted. E.x.: "httponly", "Httponly", "SameSite", any case is accepted. E.x.: "httponly", "Httponly",
"hTTPoNLY", etc. "hTTPoNLY", etc.
Servers SHOULD NOT include more than one Set-Cookie header field in Servers MUST NOT include more than one Set-Cookie header field in the
the same response with the same cookie-name. (See Section 5.6 for same response with the same cookie-name. (See Section 5.6 for how
how user agents handle this case.) user agents handle this case.)
If a server sends multiple responses containing Set-Cookie header If a server sends multiple responses containing Set-Cookie header
fields concurrently to the user agent (e.g., when communicating with fields concurrently to the user agent (e.g., when communicating with
the user agent over multiple sockets), these responses create a "race the user agent over multiple sockets), these responses create a "race
condition" that can lead to unpredictable behavior. condition" that can lead to unpredictable behavior.
NOTE: Some existing user agents differ in their interpretation of NOTE: Some existing user agents differ in their interpretation of
two-digit years. To avoid compatibility issues, servers SHOULD use two-digit years. To avoid compatibility issues, servers SHOULD use
the rfc1123-date format, which requires a four-digit year. the rfc1123-date format, which requires a four-digit year.
skipping to change at page 15, line 48 skipping to change at page 16, line 15
Although seemingly useful for isolating cookies between different Although seemingly useful for isolating cookies between different
paths within a given host, the Path attribute cannot be relied upon paths within a given host, the Path attribute cannot be relied upon
for security (see Section 8). for security (see Section 8).
4.1.2.5. The Secure Attribute 4.1.2.5. The Secure Attribute
The Secure attribute limits the scope of the cookie to "secure" The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS) secure channel (typically HTTP over Transport Layer Security (TLS
[HTTP]). [TLS13]) [HTTP]).
4.1.2.6. The HttpOnly Attribute 4.1.2.6. The HttpOnly Attribute
The HttpOnly attribute limits the scope of the cookie to HTTP The HttpOnly attribute limits the scope of the cookie to HTTP
requests. In particular, the attribute instructs the user agent to requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to cookies via non-HTTP APIs. omit the cookie when providing access to cookies via non-HTTP APIs.
Note that the HttpOnly attribute is independent of the Secure Note that the HttpOnly attribute is independent of the Secure
attribute: a cookie can have both the HttpOnly and the Secure attribute: a cookie can have both the HttpOnly and the Secure
attribute. attribute.
skipping to change at page 33, line 4 skipping to change at page 33, line 24
not be compatible with existing session management systems. In the not be compatible with existing session management systems. In the
interests of providing a drop-in mechanism that mitigates the risk of interests of providing a drop-in mechanism that mitigates the risk of
CSRF attacks, developers may set the "SameSite" attribute in a "Lax" CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
enforcement mode that carves out an exception which sends same-site enforcement mode that carves out an exception which sends same-site
cookies along with cross-site requests if and only if they are top- cookies along with cross-site requests if and only if they are top-
level navigations which use a "safe" (in the [HTTP] sense) HTTP level navigations which use a "safe" (in the [HTTP] sense) HTTP
method. (Note that a request's method may be changed from POST to method. (Note that a request's method may be changed from POST to
GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTP]); in GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTP]); in
these cases, a request's "safe"ness is determined based on the method these cases, a request's "safe"ness is determined based on the method
of the current redirect hop.) of the current redirect hop.)
Lax enforcement provides reasonable defense in depth against CSRF Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but does not attacks that rely on unsafe HTTP methods (like "POST"), but does not
offer a robust defense against CSRF as a general category of attack: offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level 1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as navigations in order to create a "same-site" request (as
described in Section 5.2.1), which is only a speedbump along the described in Section 5.2.1), which is only a speedbump along the
road to exploitation. road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be 2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user exploited to create "same-site" requests without the risk of user
detection. detection.
When possible, developers should use a session management mechanism Developers can more completely mitigate CSRF through a session
such as that described in Section 8.8.2 to mitigate the risk of CSRF management mechanism such as that described in Section 8.8.2.
more completely.
5.6.7.2. "Lax-Allowing-Unsafe" enforcement 5.6.7.2. "Lax-Allowing-Unsafe" enforcement
As discussed in Section 8.8.6, compatibility concerns may necessitate As discussed in Section 8.8.6, compatibility concerns may necessitate
the use of a "Lax-allowing-unsafe" enforcement mode that allows the use of a "Lax-allowing-unsafe" enforcement mode that allows
cookies to be sent with a cross-site HTTP request if and only if it cookies to be sent with a cross-site HTTP request if and only if it
is a top-level request, regardless of request method. That is, the is a top-level request, regardless of request method. That is, the
"Lax-allowing-unsafe" enforcement mode waives the requirement for the "Lax-allowing-unsafe" enforcement mode waives the requirement for the
HTTP request's method to be "safe" in the "SameSite" enforcement step HTTP request's method to be "safe" in the "SameSite" enforcement step
of the retrieval algorithm in Section 5.8.3. (All cookies, of the retrieval algorithm in Section 5.8.3. (All cookies,
skipping to change at page 41, line 43 skipping to change at page 42, line 16
* The retrieval's URI's path path-matches the cookie's path. * The retrieval's URI's path path-matches the cookie's path.
* If the cookie's secure-only-flag is true, then the retrieval's * If the cookie's secure-only-flag is true, then the retrieval's
URI must denote a "secure" connection (as defined by the user URI must denote a "secure" connection (as defined by the user
agent). agent).
NOTE: The notion of a "secure" connection is not defined by NOTE: The notion of a "secure" connection is not defined by
this document. Typically, user agents consider a connection this document. Typically, user agents consider a connection
secure if the connection makes use of transport-layer secure if the connection makes use of transport-layer
security, such as SSL or TLS, or if the host is trusted. For security, such as SSL or TLS [TLS13], or if the host is
example, most user agents consider "https" to be a scheme that trusted. For example, most user agents consider "https" to be
denotes a secure protocol and "localhost" to be trusted host. a scheme that denotes a secure protocol and "localhost" to be
trusted host.
* If the cookie's http-only-flag is true, then exclude the * If the cookie's http-only-flag is true, then exclude the
cookie if the retrieval's type is "non-HTTP". cookie if the retrieval's type is "non-HTTP".
* If the cookie's same-site-flag is not "None" and the * If the cookie's same-site-flag is not "None" and the
retrieval's same-site status is "cross-site", then exclude the retrieval's same-site status is "cross-site", then exclude the
cookie unless all of the following conditions are met: cookie unless all of the following conditions are met:
+ The retrieval's type is "HTTP". + The retrieval's type is "HTTP".
skipping to change at page 47, line 35 skipping to change at page 48, line 12
Instead of using cookies for authorization, server operators might Instead of using cookies for authorization, server operators might
wish to consider entangling designation and authorization by treating wish to consider entangling designation and authorization by treating
URLs as capabilities. Instead of storing secrets in cookies, this URLs as capabilities. Instead of storing secrets in cookies, this
approach stores secrets in URLs, requiring the remote entity to approach stores secrets in URLs, requiring the remote entity to
supply the secret itself. Although this approach is not a panacea, supply the secret itself. Although this approach is not a panacea,
judicious application of these principles can lead to more robust judicious application of these principles can lead to more robust
security. security.
8.3. Clear Text 8.3. Clear Text
Unless sent over a secure channel (such as TLS), the information in Unless sent over a secure channel (such as TLS [TLS13]), the
the Cookie and Set-Cookie header fields is transmitted in the clear. information in the Cookie and Set-Cookie header fields is transmitted
in the clear.
1. All sensitive information conveyed in these header fields is 1. All sensitive information conveyed in these header fields is
exposed to an eavesdropper. exposed to an eavesdropper.
2. A malicious intermediary could alter the header fields as they 2. A malicious intermediary could alter the header fields as they
travel in either direction, with unpredictable results. travel in either direction, with unpredictable results.
3. A malicious client could alter the Cookie header fields before 3. A malicious client could alter the Cookie header fields before
transmission, with unpredictable results. transmission, with unpredictable results.
skipping to change at page 58, line 16 skipping to change at page 58, line 45
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[SERVICE-WORKERS] [SERVICE-WORKERS]
Archibald, J. and M. Kruisselbrink, "Service Workers", Archibald, J. and M. Kruisselbrink, "Service Workers",
n.d., <https://www.w3.org/TR/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/info/rfc8446>.
10.3. URIs 10.3. URIs
[1] https://www.iana.org/assignments/cookie-attribute-names [1] https://www.iana.org/assignments/cookie-attribute-names
Appendix A. Changes from RFC 6265 Appendix A. Changes from RFC 6265
o Adds the same-site concept and the SameSite attribute. o Adds the same-site concept and the SameSite attribute.
(Section 5.2 and Section 4.1.2.7) (Section 5.2 and Section 4.1.2.7)
o Introduces cookie prefixes and prohibits nameless cookies from o Introduces cookie prefixes and prohibits nameless cookies from
 End of changes. 33 change blocks. 
69 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/