draft-ietf-httpbis-rfc6265bis-13.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: May 18, 2024 Apple, Inc Expires: September 22, 2024 Apple, Inc
November 15, 2023 March 21, 2024
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-13 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 May 18, 2024. This Internet-Draft will expire on September 22, 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 19 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 19
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 21 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . 25
5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 26 5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 25
5.5. The Set-Cookie Header Field . . . . . . . . . . . . . . . 27 5.5. The Set-Cookie Header Field . . . . . . . . . . . . . . . 27
5.5.1. The Expires Attribute . . . . . . . . . . . . . . . . 30 5.5.1. The Expires Attribute . . . . . . . . . . . . . . . . 30
5.5.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 30 5.5.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 30
5.5.3. The Domain Attribute . . . . . . . . . . . . . . . . 31 5.5.3. The Domain Attribute . . . . . . . . . . . . . . . . 31
5.5.4. The Path Attribute . . . . . . . . . . . . . . . . . 31 5.5.4. The Path Attribute . . . . . . . . . . . . . . . . . 31
5.5.5. The Secure Attribute . . . . . . . . . . . . . . . . 31 5.5.5. The Secure Attribute . . . . . . . . . . . . . . . . 31
5.5.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32 5.5.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32
5.5.7. The SameSite Attribute . . . . . . . . . . . . . . . 32 5.5.7. The SameSite Attribute . . . . . . . . . . . . . . . 32
5.6. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34 5.6. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34
5.7. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 40 5.7. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 39
5.7.1. The Cookie Header Field . . . . . . . . . . . . . . . 40 5.7.1. The Cookie Header Field . . . . . . . . . . . . . . . 40
5.7.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 40 5.7.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 40
5.7.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 41 5.7.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 40
6. Implementation Considerations . . . . . . . . . . . . . . . . 42 6. Implementation Considerations . . . . . . . . . . . . . . . . 42
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Application Programming Interfaces . . . . . . . . . . . 43 6.2. Application Programming Interfaces . . . . . . . . . . . 43
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 43 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 43
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45
7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45
7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46
7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 47 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 47
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 48 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 48
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 49 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 49
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 49 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 49
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 50 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 50
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 50 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 50
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 50 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 50
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 . . . . . . . . . . . . . . . . . 52
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 . . . . . . . . . . . . . . . . . . . . . . . . . 53 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 . . . . . . . . . . . . . . . . 54
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 54 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 55
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 57
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 61 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 62
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 61 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 62
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 61 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 62
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 62 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 62
A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 62 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 63
A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 62 A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 63
A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 63 A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 63
A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 63 A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 64
A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 63 A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 64
A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 64 A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 64
A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 64 A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 65
A.11. draft-ietf-httpbis-rfc6265bis-10 . . . . . . . . . . . . 65 A.11. draft-ietf-httpbis-rfc6265bis-10 . . . . . . . . . . . . 65
A.12. draft-ietf-httpbis-rfc6265bis-11 . . . . . . . . . . . . 65 A.12. draft-ietf-httpbis-rfc6265bis-11 . . . . . . . . . . . . 66
A.13. draft-ietf-httpbis-rfc6265bis-12 . . . . . . . . . . . . 66 A.13. draft-ietf-httpbis-rfc6265bis-12 . . . . . . . . . . . . 66
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66 A.14. draft-ietf-httpbis-rfc6265bis-14 . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
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.
Although simple on their surface, cookies have a number of Although simple on their surface, cookies have a number of
complexities. For example, the server indicates a scope for each complexities. For example, the server indicates a scope for each
cookie when sending it to the user agent. The scope indicates the cookie when sending it to the user agent. The scope indicates the
maximum amount of time in which the user agent should return the maximum amount of time in which the user agent should return the
cookie, the servers to which the user agent should return the cookie, cookie, the servers to which the user agent should return the cookie,
and the URI schemes for which the cookie is applicable. and the connection types for which the cookie is applicable.
For historical reasons, cookies contain a number of security and For historical reasons, cookies contain a number of security and
privacy infelicities. For example, a server can indicate that a privacy infelicities. For example, a server can indicate that a
given cookie is intended for "secure" connections, but the Secure given cookie is intended for "secure" connections, but the Secure
attribute does not provide integrity in the presence of an active attribute does not provide integrity in the presence of an active
network attacker. Similarly, cookies for a given host are shared network attacker. Similarly, cookies for a given host are shared
across all the ports on that host, even though the usual "same-origin across all the ports on that host, even though the usual "same-origin
policy" used by web browsers isolates content retrieved via different policy" used by web browsers isolates content retrieved via different
ports. ports.
skipping to change at page 18, line 36 skipping to change at page 18, line 36
The user agent sends stored cookies to the origin server in the The user agent sends stored cookies to the origin server in the
Cookie header field. If the server conforms to the requirements in Cookie header field. If the server conforms to the requirements in
Section 4.1 (and the user agent conforms to the requirements in Section 4.1 (and the user agent conforms to the requirements in
Section 5), the user agent will send a Cookie header field that Section 5), the user agent will send a Cookie header field that
conforms to the following grammar: conforms to the following grammar:
cookie = cookie-string cookie = cookie-string
cookie-string = cookie-pair *( ";" SP cookie-pair ) cookie-string = cookie-pair *( ";" SP cookie-pair )
Servers MUST be tolerant of multiple cookie headers. For example, an
HTTP/2 [RFC9113] or HTTP/3 [RFC9114] connection might split a cookie
header to improve compression.
4.2.2. Semantics 4.2.2. Semantics
Each cookie-pair represents a cookie stored by the user agent. The Each cookie-pair represents a cookie stored by the user agent. The
cookie-pair contains the cookie-name and cookie-value the user agent cookie-pair contains the cookie-name and cookie-value the user agent
received in the Set-Cookie header field. received in the Set-Cookie header field.
Notice that the cookie attributes are not returned. In particular, Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie field alone when a cookie the server cannot determine from the Cookie field alone when a cookie
will expire, for which hosts the cookie is valid, for which paths the will expire, for which hosts the cookie is valid, for which paths the
cookie is valid, or whether the cookie was set with the Secure or cookie is valid, or whether the cookie was set with the Secure or
skipping to change at page 23, line 15 skipping to change at page 23, line 15
o The cookie-path is a prefix of the request-path, and the first o The cookie-path is a prefix of the request-path, and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. "Same-site" and "cross-site" Requests 5.2. "Same-site" and "cross-site" Requests
Two origins are same-site if they satisfy the "same site" criteria Two origins are same-site if they satisfy the "same site" criteria
defined in [SAMESITE]. A request is "same-site" if the following defined in [SAMESITE]. A request is "same-site" if the following
criteria are true: criteria are true:
1. The request is not the result of a cross-site redirect. That is, 1. The request is not the result of a reload navigation triggered
the origin of every url in the request's url list is same-site
with the request's current url's origin.
2. The request is not the result of a reload navigation triggered
through a user interface element (as defined by the user agent; through a user interface element (as defined by the user agent;
e.g., a request triggered by the user clicking a refresh button e.g., a request triggered by the user clicking a refresh button
on a toolbar). on a toolbar).
3. The request's current url's origin is same-site with the 2. The request's current url's origin is same-site with the
request's client's "site for cookies" (which is an origin), or if request's client's "site for cookies" (which is an origin), or if
the request has no client or the request's client is null. the request has no client or the request's client is null.
Requests which are the result of a reload navigation triggered Requests which are the result of a reload navigation triggered
through a user interface element are same-site if the reloaded through a user interface element are same-site if the reloaded
document was originally navigated to via a same-site request. A document was originally navigated to via a same-site request. A
request that is not "same-site" is instead "cross-site". request that is not "same-site" is instead "cross-site".
The request's client's "site for cookies" is calculated depending The request's client's "site for cookies" is calculated depending
upon its client's type, as described in the following subsections: upon its client's type, as described in the following subsections:
skipping to change at page 36, line 39 skipping to change at page 36, line 39
attribute-name of "Path", set the cookie's path to attribute- attribute-name of "Path", set the cookie's path to attribute-
value of the last attribute in the cookie-attribute-list with value of the last attribute in the cookie-attribute-list with
both an attribute-name of "Path" and an attribute-value whose both an attribute-name of "Path" and an attribute-value whose
length is no more than 1024 octets. Otherwise, set the cookie's length is no more than 1024 octets. Otherwise, set the cookie's
path to the default-path of the request-uri. path to the default-path of the request-uri.
12. If the cookie-attribute-list contains an attribute with an 12. If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to attribute-name of "Secure", set the cookie's secure-only-flag to
true. Otherwise, set the cookie's secure-only-flag to false. true. Otherwise, set the cookie's secure-only-flag to false.
13. If the scheme component of the request-uri does not denote a 13. If the request-uri does not denote a "secure" connection (as
"secure" protocol (as defined by the user agent), and the defined by the user agent), and the cookie's secure-only-flag is
cookie's secure-only-flag is true, then abort these steps and true, then abort these steps and ignore the cookie entirely.
ignore the cookie entirely.
14. If the cookie-attribute-list contains an attribute with an 14. If the cookie-attribute-list contains an attribute with an
attribute-name of "HttpOnly", set the cookie's http-only-flag to attribute-name of "HttpOnly", set the cookie's http-only-flag to
true. Otherwise, set the cookie's http-only-flag to false. true. Otherwise, set the cookie's http-only-flag to false.
15. If the cookie was received from a "non-HTTP" API and the 15. If the cookie was received from a "non-HTTP" API and the
cookie's http-only-flag is true, abort these steps and ignore cookie's http-only-flag is true, abort these steps and ignore
the cookie entirely. the cookie entirely.
16. If the cookie's secure-only-flag is false, and the scheme 16. If the cookie's secure-only-flag is false, and the request-uri
component of request-uri does not denote a "secure" protocol, does not denote a "secure" connection, then abort these steps
then abort these steps and ignore the cookie entirely if the and ignore the cookie entirely if the cookie store contains one
cookie store contains one or more cookies that meet all of the or more cookies that meet all of the following criteria:
following criteria:
1. Their name matches the name of the newly-created cookie. 1. Their name matches the name of the newly-created cookie.
2. Their secure-only-flag is true. 2. Their secure-only-flag is true.
3. Their domain domain-matches the domain of the newly-created 3. Their domain domain-matches the domain of the newly-created
cookie, or vice-versa. cookie, or vice-versa.
4. The path of the newly-created cookie path-matches the path 4. The path of the newly-created cookie path-matches the path
of the existing cookie. of the existing cookie.
skipping to change at page 40, line 21 skipping to change at page 40, line 12
may be required in order to return a cookie-string from a call to a may be required in order to return a cookie-string from a call to a
"non-HTTP" API that provides access to cookies. A retrieval has an "non-HTTP" API that provides access to cookies. A retrieval has an
associated URI, same-site status, and type, which are defined below associated URI, same-site status, and type, which are defined below
depending on the type of retrieval. depending on the type of retrieval.
5.7.1. The Cookie Header Field 5.7.1. The Cookie Header Field
The user agent includes stored cookies in the Cookie HTTP request The user agent includes stored cookies in the Cookie HTTP request
header field. header field.
When the user agent generates an HTTP request, the user agent MUST
NOT attach more than one Cookie header field.
A user agent MAY omit the Cookie header field in its entirety. For A user agent MAY omit the Cookie header field in its entirety. For
example, the user agent might wish to block sending cookies during example, the user agent might wish to block sending cookies during
"third-party" requests from setting cookies (see Section 7.1). "third-party" requests from setting cookies (see Section 7.1).
If the user agent does attach a Cookie header field to an HTTP If the user agent does attach a Cookie header field to an HTTP
request, the user agent MUST compute the cookie-string following the request, the user agent MUST generate a single cookie-string and the
algorithm defined in Section 5.7.3, where the retrieval's URI is the user agent MUST compute the cookie-string following the algorithm
request-uri, the retrieval's same-site status is computed for the defined in Section 5.7.3, where the retrieval's URI is the request-
HTTP request as defined in Section 5.2, and the retrieval's type is uri, the retrieval's same-site status is computed for the HTTP
request as defined in Section 5.2, and the retrieval's type is
"HTTP". "HTTP".
5.7.2. Non-HTTP APIs 5.7.2. Non-HTTP APIs
The user agent MAY implement "non-HTTP" APIs that can be used to The user agent MAY implement "non-HTTP" APIs that can be used to
access stored cookies. access stored cookies.
A user agent MAY return an empty cookie-string in certain contexts, A user agent MAY return an empty cookie-string in certain contexts,
such as when a retrieval occurs within a third-party context (see such as when a retrieval occurs within a third-party context (see
Section 7.1). Section 7.1).
skipping to change at page 41, line 37 skipping to change at page 41, line 27
cookie was created. If this change results in a cookie's cookie was created. If this change results in a cookie's
domain becoming a public suffix then that cookie is considered domain becoming a public suffix then that cookie is considered
invalid as it would have been rejected during creation (See invalid as it would have been rejected during creation (See
Section 5.6 step 9). User agents should be careful to avoid Section 5.6 step 9). User agents should be careful to avoid
retrieving these invalid cookies even if they domain-match the retrieving these invalid cookies even if they domain-match the
host of the retrieval's URI. host of the retrieval's URI.
* 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's scheme must denote a "secure" protocol (as defined by URI must denote a "secure" connection (as defined by the user
the user agent). agent).
NOTE: The notion of a "secure" protocol is not defined by this NOTE: The notion of a "secure" connection is not defined by
document. Typically, user agents consider a protocol secure this document. Typically, user agents consider a connection
if the protocol makes use of transport-layer security, such as secure if the connection makes use of transport-layer
SSL or TLS. For example, most user agents consider "https" to security, such as SSL or TLS, or if host is trusted. For
be a scheme that denotes a secure protocol. example, most user agents consider "https" to be 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 45, line 46 skipping to change at page 45, line 44
User agents MAY enforce a cookie policy consisting of restrictions on User agents MAY enforce a cookie policy consisting of restrictions on
how cookies may be used or ignored (see Section 5.3). how cookies may be used or ignored (see Section 5.3).
A cookie policy may govern which domains or parties, as in first and A cookie policy may govern which domains or parties, as in first and
third parties (see Section 7.1), for which the user agent will allow third parties (see Section 7.1), for which the user agent will allow
cookie access. The policy can also define limits on cookie size, cookie access. The policy can also define limits on cookie size,
cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the
number of cookies per domain or in total. number of cookies per domain or in total.
The recomended cookie expiry upper limit is 400 days. User agents The recommended cookie expiry upper limit is 400 days. User agents
may set a lower limit to enforce shorter data retention timelines, or may set a lower limit to enforce shorter data retention timelines, or
set the limit higher to support longer retention when appropriate set the limit higher to support longer retention when appropriate
(e.g., server-to-server communication over HTTPS). (e.g., server-to-server communication over HTTPS).
The goal of a restrictive cookie policy is often to improve security The goal of a restrictive cookie policy is often to improve security
or privacy. User agents often allow users to change the cookie or privacy. User agents often allow users to change the cookie
policy (see Section 7.3). policy (see Section 7.3).
7.3. User Controls 7.3. User Controls
skipping to change at page 51, line 6 skipping to change at page 50, line 51
8.8. SameSite Cookies 8.8. SameSite Cookies
8.8.1. Defense in depth 8.8.1. Defense in depth
"SameSite" cookies offer a robust defense against CSRF attack when "SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is, deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of however, prudent to ensure that this designation is not the extent of
a site's defense against CSRF, as same-site navigations and a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting. attack vectors such as cross-site scripting or abuse of page
redirections.
Understanding how and when a request is considered same-site is also
important in order to properly design a site for SameSite cookies.
For example, if a top-level request is made to a sensitive page that
request will be considered cross-site and SameSite cookies won't be
sent; that page's sub-resources requests, however, are same-site and
would receive SameSite cookies. Sites can avoid inadvertently
allowing access to these sub-resources by returning an error for the
initial page request if it doesn't include the appropriate cookies.
Developers are strongly encouraged to deploy the usual server-side Developers are strongly encouraged to deploy the usual server-side
defenses (CSRF tokens, ensuring that "safe" HTTP methods are defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully. idempotent, etc) to mitigate the risk more fully.
Additionally, client-side techniques such as those described in Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are [app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies. certainly worth exploring in combination with "SameSite" cookies.
8.8.2. Top-level Navigations 8.8.2. Top-level Navigations
skipping to change at page 53, line 10 skipping to change at page 53, line 19
because the site only displays its sensitive content if a particular because the site only displays its sensitive content if a particular
"SameSite" cookie is present in the request. The user, frustrated by "SameSite" cookie is present in the request. The user, frustrated by
the unexpectedly broken site, presses refresh on their browser's the unexpectedly broken site, presses refresh on their browser's
toolbar. To now consider the reload request same-site and send the toolbar. To now consider the reload request same-site and send the
initially withheld "SameSite" cookie would defeat the purpose of initially withheld "SameSite" cookie would defeat the purpose of
withholding it in the first place, as the reload navigation triggered withholding it in the first place, as the reload navigation triggered
through the user interface may replay the original (potentially through the user interface may replay the original (potentially
malicious) request. Thus, the reload request should be considered malicious) request. Thus, the reload request should be considered
cross-site, like the request that initially navigated to the page. cross-site, like the request that initially navigated to the page.
Because requests issued for, non-user initiated, reloads attach all
SameSite cookies, developers should be careful and thoughtful about
when to initiate a reload in order to avoid a CSRF attack. For
example, the page could only initiate a reload if a CSRF token is
present on the initial request.
8.8.6. Top-level requests with "unsafe" methods 8.8.6. Top-level requests with "unsafe" methods
The "Lax" enforcement mode described in Section 5.5.7.1 allows a The "Lax" enforcement mode described in Section 5.5.7.1 allows a
cookie to be sent with a cross-site HTTP request if and only if it is cookie to be sent with a cross-site HTTP request if and only if it is
a top-level navigation with a "safe" HTTP method. Implementation a top-level navigation with a "safe" HTTP method. Implementation
experience shows that this is difficult to apply as the default experience shows that this is difficult to apply as the default
behavior, as some sites may rely on cookies not explicitly specifying behavior, as some sites may rely on cookies not explicitly specifying
a "SameSite" attribute being included on top-level cross-site a "SameSite" attribute being included on top-level cross-site
requests with "unsafe" HTTP methods (as was the case prior to the requests with "unsafe" HTTP methods (as was the case prior to the
introduction of the "SameSite" attribute). introduction of the "SameSite" attribute).
skipping to change at page 58, line 27 skipping to change at page 58, line 40
<https://www.rfc-editor.org/info/rfc5895>. <https://www.rfc-editor.org/info/rfc5895>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame- [RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
Options", RFC 7034, DOI 10.17487/RFC7034, October 2013, Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
<https://www.rfc-editor.org/info/rfc7034>. <https://www.rfc-editor.org/info/rfc7034>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", UNICODE Unicode Technical Standards # 46, Processing", UNICODE Unicode Technical Standards # 46,
June 2016, <http://unicode.org/reports/tr46/>. June 2016, <http://unicode.org/reports/tr46/>.
10.3. URIs 10.3. URIs
[1] https://www.iana.org/assignments/cookie-attribute-names [1] https://www.iana.org/assignments/cookie-attribute-names
[2] https://github.com/httpwg/http-extensions/issues/243 [2] https://github.com/httpwg/http-extensions/issues/243
skipping to change at page 61, line 21 skipping to change at page 61, line 43
[62] https://github.com/httpwg/http-extensions/pull/2244 [62] https://github.com/httpwg/http-extensions/pull/2244
[63] https://github.com/httpwg/http-extensions/pull/2251 [63] https://github.com/httpwg/http-extensions/pull/2251
[64] https://github.com/httpwg/http-extensions/pull/2478 [64] https://github.com/httpwg/http-extensions/pull/2478
[65] https://github.com/httpwg/http-extensions/pull/2481 [65] https://github.com/httpwg/http-extensions/pull/2481
[66] https://github.com/httpwg/http-extensions/pull/2478 [66] https://github.com/httpwg/http-extensions/pull/2478
[67] https://github.com/httpwg/http-extensions/pull/2753
[68] https://github.com/httpwg/http-extensions/pull/2759
[69] https://github.com/httpwg/http-extensions/pull/2758
[70] https://github.com/httpwg/http-extensions/pull/2750
Appendix A. Changes Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00 A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes. o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01 A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to o Fixes to formatting caused by mistakes in the initial port to
Markdown: Markdown:
skipping to change at page 66, line 22 skipping to change at page 67, line 5
o Advise the reader which section to implement o Advise the reader which section to implement
https://github.com/httpwg/http-extensions/pull/2478 [64] https://github.com/httpwg/http-extensions/pull/2478 [64]
o Define top-level navigation https://github.com/httpwg/http- o Define top-level navigation https://github.com/httpwg/http-
extensions/pull/2481 [65] extensions/pull/2481 [65]
o Use navigables concept https://github.com/httpwg/http-extensions/ o Use navigables concept https://github.com/httpwg/http-extensions/
pull/2478 [66] pull/2478 [66]
A.14. draft-ietf-httpbis-rfc6265bis-14
o Refactor cookie header text https://github.com/httpwg/http-
extensions/pull/2753 [67]
o Support potentially trustworthy origins https://github.com/httpwg/
http-extensions/pull/2759 [68]
o Add additional developer warnings for SameSite cookies
https://github.com/httpwg/http-extensions/pull/2758 [69]
o Remove consideration of same-site redirect chain
https://github.com/httpwg/http-extensions/pull/2750 [70]
Acknowledgements Acknowledgements
RFC 6265 was written by Adam Barth. This document is an update of RFC 6265 was written by Adam Barth. This document is an update of
RFC 6265, adding features and aligning the specification with the RFC 6265, adding features and aligning the specification with the
reality of today's deployments. Here, we're standing upon the reality of today's deployments. Here, we're standing upon the
shoulders of a giant since the majority of the text is still Adam's. shoulders of a giant since the majority of the text is still Adam's.
Thank you to both Lily Chen and Steven Englehardt, editors emeritus, Thank you to both Lily Chen and Steven Englehardt, editors emeritus,
for their significant contributions improving this draft. for their significant contributions improving this draft.
 End of changes. 32 change blocks. 
57 lines changed or deleted 100 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/