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 7, 2025 Apple, Inc
January 7, 2025 February 3, 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 7, 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 3, line 33 skipping to change at page 3, line 33
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 . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . . . . . 40
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 . . . . . . . . . . . 43
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 . . . . . . . . . . . . . . . . . . . . . . 45
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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 54
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54
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 . . . . . . . . . . . . . . . . . . 55
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 56
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 58 Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 58
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 59 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 59
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 15, line 48 skipping to change at page 15, line 48
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 17 skipping to change at page 33, line 17
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 41, line 43
* 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 47, line 40
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 24
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. 14 change blocks. 
22 lines changed or deleted 27 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/