draft-ietf-httpbis-rfc6265bis-21.txt		draft-ietf-httpbis-rfc6265bis-latest.txt
	HTTP Working Group S. Bingler, Ed.		HTTP Working Group S. Bingler, Ed.
	Internet-Draft		Internet-Draft
	Obsoletes: 6265 (if approved) M. West, Ed.		Obsoletes: 6265 (if approved) M. West, Ed.
	Intended status: Standards Track Google LLC		Intended status: Standards Track Google LLC
	Expires: March 28, 2026 J. Wilander, Ed.		Expires: May 21, 2026 J. Wilander, Ed.
	Apple, Inc		Apple, Inc
	September 24, 2025		November 17, 2025
	Cookies: HTTP State Management Mechanism		Cookies: HTTP State Management Mechanism
	draft-ietf-httpbis-rfc6265bis-21		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 10 ¶		skipping to change at page 2, line 10 ¶
	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 March 28, 2026.		This Internet-Draft will expire on May 21, 2026.
	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 52 ¶		skipping to change at page 2, line 52 ¶
	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 . . . . . . . . . . . . . 10		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 . . . . . . . . . . 11		3.2.2. Cookie Consuming Implementations . . . . . . . . . . 11
	4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11		4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Set-Cookie Header . . . . . . . . . . . . . . . . . . . . 12
	4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12		4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14		4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14
	4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 17		4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 17
	4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.2. Cookie Header . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 20		5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 20
	5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 20		5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 22		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 . . . . . . . . . . . . . . . 24		5.2.1. Document-based requests . . . . . . . . . . . . . . . 24
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	6.2. Application Programming Interfaces . . . . . . . . . . . 43		6.2. Application Programming Interfaces . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 47		8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47
	8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47		8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47
	8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 48		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 . . . . . . . . . . . . . . . . . . . . . 50		8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 50
	8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 51		8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 51
	8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 51		8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 51
	8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 51		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 . . . . . . . . . . . . . . . . . 52		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 . . . . . . . . . . . . . . . . . . . . . 54		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 Attributes" Registry . . . . . . . . . . . . . . 55		9.3. "Cookie Attributes" Registry . . . . . . . . . . . . . . 55
	9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55		9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55
	9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55		9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
	10.1. Normative References . . . . . . . . . . . . . . . . . . 55		10.1. Normative References . . . . . . . . . . . . . . . . . . 56
	10.2. Informative References . . . . . . . . . . . . . . . . . 57		10.2. Informative References . . . . . . . . . . . . . . . . . 57
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
	Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59		Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60		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
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 42 ¶
	If the server wishes the user agent to persist the cookie over		If the server wishes the user agent to persist the cookie over
	multiple "sessions" (e.g., user agent restarts), the server can		multiple "sessions" (e.g., user agent restarts), the server can
	specify an expiration date in the Expires attribute. Note that the		specify an expiration date in the Expires attribute. Note that the
	user agent might delete the cookie before the expiration date if the		user agent might delete the cookie before the expiration date if the
	user agent's cookie store exceeds its quota or if the user manually		user agent's cookie store exceeds its quota or if the user manually
	deletes the server's cookie.		deletes the server's cookie.
	== Server -> User Agent ==		== Server -> User Agent ==
	Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT		Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2026 10:18:14 GMT
	== User Agent -> Server ==		== User Agent -> Server ==
	Cookie: SID=31d4d96e407aad42; lang=en-US		Cookie: SID=31d4d96e407aad42; lang=en-US
	Finally, to remove a cookie, the server returns a Set-Cookie header		Finally, to remove a cookie, the server returns a Set-Cookie header
	field with an expiration date in the past. The server will be		field with an expiration date in the past. The server will be
	successful in removing the cookie only if the Path and the Domain		successful in removing the cookie only if the Path and the Domain
	attribute in the Set-Cookie header field match the values used when		attribute in the Set-Cookie header field match the values used when
	the cookie was created.		the cookie was created.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Section 4's requirements.		Section 4's requirements.
	Doing so will reduce the chances that a developer's application can		Doing so will reduce the chances that a developer's application can
	inadvertently create cookies that cannot be read by other servers.		inadvertently create cookies that cannot be read by other servers.
	4. Server Requirements		4. Server Requirements
	This section describes the syntax and semantics of a well-behaved		This section describes the syntax and semantics of a well-behaved
	profile of the Cookie and Set-Cookie header fields.		profile of the Cookie and Set-Cookie header fields.
	4.1. Set-Cookie		4.1. Set-Cookie Header
	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 conforming to this profile MUST NOT		attribute-value pairs. Servers conforming to this profile MUST NOT
	send Set-Cookie header fields that deviate from the following		send Set-Cookie header fields that deviate from the following
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 47 ¶
	; digits 1 through 9		; digits 1 through 9
	domain-av = "Domain" BWS "=" BWS domain-value		domain-av = "Domain" BWS "=" BWS domain-value
	domain-value = <subdomain>		domain-value = <subdomain>
	; see details below		; see details below
	path-av = "Path" BWS "=" BWS path-value		path-av = "Path" BWS "=" BWS path-value
	path-value = *av-octet		path-value = *av-octet
	secure-av = "Secure"		secure-av = "Secure"
	httponly-av = "HttpOnly"		httponly-av = "HttpOnly"
	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 = 1*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 MUST 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.
	skipping to change at page 13, line 24 ¶		skipping to change at page 13, line 24 ¶
	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
	characters. Note that in this case, the initial and trailing DQUOTE		characters. Note that in this case, the initial and trailing DQUOTE
	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.
	Per the grammar above, cookie-avs MUST NOT contain leading or		Per the grammar above, extension-av MUST NOT contain leading or
	trailing WSP characters as they will be interpreted as BWS and		trailing WSP characters as they will be interpreted as BWS and
	removed.		removed.
	The domain-value is a subdomain as defined by Section 3.5 of		The domain-value is a subdomain as defined by Section 3.5 of
	[RFC1034], and as enhanced by Section 2.1 of [RFC1123]. Thus,		[RFC1034], and as enhanced by Section 2.1 of [RFC1123]. Thus,
	domain-value is a string of [USASCII] characters, such as an		domain-value is a string of [USASCII] characters, such as an
	"A-label" as defined in Section 2.3.2.1 of [RFC5890].		"A-label" as defined in 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,
	skipping to change at page 18, line 37 ¶		skipping to change at page 18, line 37 ¶
	Set-Cookie: __Host-SID=12345; Secure		Set-Cookie: __Host-SID=12345; Secure
	Set-Cookie: __Host-SID=12345; Domain=site.example		Set-Cookie: __Host-SID=12345; Domain=site.example
	Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/		Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
	Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/		Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
	While the following would be accepted if set from a secure origin		While the following would be accepted if set from a secure origin
	(e.g. "https://site.example/"), and rejected otherwise:		(e.g. "https://site.example/"), and rejected otherwise:
	Set-Cookie: __Host-SID=12345; Secure; Path=/		Set-Cookie: __Host-SID=12345; Secure; Path=/
	4.2. Cookie		4.2. Cookie Header
	4.2.1. Syntax		4.2.1. Syntax
	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
	skipping to change at page 24, line 12 ¶		skipping to change at page 24, line 12 ¶
	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:
	5.2.1. Document-based requests		5.2.1. Document-based requests
	The URI displayed in a user agent's address bar is the only security		The URI displayed in a user agent's address bar is the only security
	context directly exposed to users, and therefore the only signal		context directly exposed to users, and therefore the only signal
	users can reasonably rely upon to determine whether or not they trust		users can reasonably rely upon to determine whether or not they trust
	a particular website. The origin of that URI represents the context		a particular website. The origin of that URI represents the context
	in which a user most likely believes themselves to be interacting.		in which a user most likely believes themselves to be interacting.
	We'll define this origin, the top-level traversable's active		This origin, the top-level traversable's active document's origin, is
	document's origin, as the "top-level origin".		defined as the "top-level origin".
	For a document displayed in a top-level traversable, we can stop		For a document displayed in a top-level traversable, the document's
	here: the document's "site for cookies" is the top-level origin.		"site for cookies" is the top-level origin.
	For container documents, we need to audit the origins of each of a		For container documents, the origins of each of a document's ancestor
	document's ancestor navigables' active documents in order to account		navigables' active documents must be audited in order to account for
	for the "multiple-nested scenarios" described in Section 4 of		the "multiple-nested scenarios" described in Section 4 of [RFC7034].
	[RFC7034]. A document's "site for cookies" is the top-level origin		A document's "site for cookies" is the top-level origin if and only
	if and only if the top-level origin is same-site with the document's		if the top-level origin is same-site with the document's origin, and
	origin, and with each of the document's ancestor documents' origins.		with each of the document's ancestor documents' origins. Otherwise
	Otherwise its "site for cookies" is an origin set to an opaque		its "site for cookies" is an origin set to an opaque origin.
	origin.
	Given a Document ("document"), the following algorithm returns its		Given a Document ("document"), the following algorithm returns its
	"site for cookies":		"site for cookies":
	1. Let "top-document" be the active document in "document"'s		1. Let "top-document" be the active document in "document"'s
	navigable's top-level traversable.		navigable's top-level traversable.
	2. Let "top-origin" be the origin of "top-document"'s URI if "top-		2. Let "top-origin" be the origin of "top-document"'s URI if "top-
	document"'s sandboxed origin browsing context flag is set, and		document"'s sandboxed origin browsing context flag is set, and
	"top-document"'s origin otherwise.		"top-document"'s origin otherwise.
	skipping to change at page 47, line 22 ¶		skipping to change at page 47, line 22 ¶
	session identifiers in cookies, developers often create session		session identifiers in cookies, developers often create session
	fixation vulnerabilities.		fixation vulnerabilities.
	Transport-layer encryption, such as that employed in HTTPS, offers a		Transport-layer encryption, such as that employed in HTTPS, offers a
	significant layer of defense against network attacks on cookies.		significant layer of defense against network attacks on cookies.
	However, it is insufficient in fully preventing a networking attacker		However, it is insufficient in fully preventing a networking attacker
	from obtaining or altering a victim's cookies because of inherent		from obtaining or altering a victim's cookies because of inherent
	vulnerabilities in the cookie protocol itself (see "Weak		vulnerabilities in the cookie protocol itself (see "Weak
	Confidentiality" and "Weak Integrity", below). In addition, by		Confidentiality" and "Weak Integrity", below). In addition, by
	default, cookies do not provide confidentiality or integrity from		default, cookies do not provide confidentiality or integrity from
	network attackers, even when used in conjunction with HTTPS.		network attackers, even when used in conjunction with HTTPS. This
			means that a cookie needs to explicitly specify any protective
			attributes. For example, the cookie:
			"Set-Cookie: a=b"
			doesn't specify the Secure attribute and will therefore be accessible
			on both secure and insecure connections, regardless of the original
			connection type it was created on. This behavior could allow an
			attacker to read or modify the cookie.
	8.2. Ambient Authority		8.2. Ambient Authority
	A server that uses cookies to authenticate users can suffer security		A server that uses cookies to authenticate users can suffer security
	vulnerabilities because some user agents let remote parties issue		vulnerabilities because some user agents let remote parties issue
	HTTP requests from the user agent (e.g., via HTTP redirects or HTML		HTTP requests from the user agent (e.g., via HTTP redirects or HTML
	forms). When issuing those requests, user agents attach cookies even		forms). When issuing those requests, user agents attach cookies even
	if the remote party does not know the contents of the cookies,		if the remote party does not know the contents of the cookies,
	potentially letting the remote party exercise authority at an unwary		potentially letting the remote party exercise authority at an unwary
	server.		server.
	skipping to change at page 55, line 48 ¶		skipping to change at page 56, line 10 ¶
	| Path | Section 4.1.2.4 of this document |		| Path | Section 4.1.2.4 of this document |
	| SameSite | Section 4.1.2.7 of this document |		| SameSite | Section 4.1.2.7 of this document |
	| Secure | Section 4.1.2.5 of this document |		| Secure | Section 4.1.2.5 of this document |
	+----------+----------------------------------+		+----------+----------------------------------+
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[DOM-DOCUMENT-COOKIE]		[DOM-DOCUMENT-COOKIE]
	WHATWG, "HTML - Living Standard", May 2021,		van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
	<https://html.spec.whatwg.org/#dom-document-cookie>.		Jaegenstedt, P., and S. Pieters, "HTML - Living Standard",
			n.d., <https://html.spec.whatwg.org/#dom-document-cookie>.
			WHATWG
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	skipping to change at page 57, line 6 ¶		skipping to change at page 57, line 15 ¶
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[SAMESITE]		[SAMESITE]
	WHATWG, "HTML - Living Standard", January 2021,		van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
	<https://html.spec.whatwg.org/#same-site>.		Jaegenstedt, P., and S. Pieters, "HTML Living Standard",
			n.d., <https://html.spec.whatwg.org/#same-site>.
			WHATWG
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	10.2. Informative References		10.2. Informative References
	[Aggarwal2010]		[Aggarwal2010]
	Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,		Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
	"An Analysis of Private Browsing Modes in Modern		"An Analysis of Private Browsing Modes in Modern
End of changes. 20 change blocks.
	32 lines changed or deleted		46 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/