draft-ietf-httpbis-rfc6265bis-08.txt   draft-ietf-httpbis-rfc6265bis-09.txt 
HTTP L. Chen, Ed. HTTP L. Chen, Ed.
Internet-Draft Google LLC Internet-Draft Google LLC
Obsoletes: 6265 (if approved) S. Englehardt, Ed. Obsoletes: 6265 (if approved) S. Englehardt, Ed.
Intended status: Standards Track Mozilla Intended status: Standards Track Mozilla
Expires: 4 December 2021 M. West, Ed. Expires: 22 April 2022 M. West, Ed.
Google LLC Google LLC
J. Wilander, Ed. J. Wilander, Ed.
Apple, Inc Apple, Inc
2 June 2021 19 October 2021
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-08 draft-ietf-httpbis-rfc6265bis-09
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 4 December 2021. This Internet-Draft will expire on 22 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 52 skipping to change at page 2, line 52
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
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19
5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20
5.2.1. Document-based requests . . . . . . . . . . . . . . . 21 5.2.1. Document-based requests . . . . . . . . . . . . . . . 21
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22
5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 23 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 23
5.4. The Set-Cookie Header Field . . . . . . . . . . . . . . . 23 5.4. The Set-Cookie Header Field . . . . . . . . . . . . . . . 23
5.4.1. The Expires Attribute . . . . . . . . . . . . . . . . 26 5.4.1. The Expires Attribute . . . . . . . . . . . . . . . . 26
5.4.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26 5.4.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26
5.4.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 5.4.3. The Domain Attribute . . . . . . . . . . . . . . . . 26
5.4.4. The Path Attribute . . . . . . . . . . . . . . . . . 27 5.4.4. The Path Attribute . . . . . . . . . . . . . . . . . 27
5.4.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 5.4.5. The Secure Attribute . . . . . . . . . . . . . . . . 27
5.4.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 5.4.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27
5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 28 5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 27
5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 30 5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 29
5.6. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 35 5.6. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 35
5.6.1. The Cookie Header Field . . . . . . . . . . . . . . . 35 5.6.1. The Cookie Header Field . . . . . . . . . . . . . . . 35
5.6.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 35 5.6.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 36
5.6.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 36 5.6.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 36
6. Implementation Considerations . . . . . . . . . . . . . . . . 38 6. Implementation Considerations . . . . . . . . . . . . . . . . 38
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2. Application Programming Interfaces . . . . . . . . . . . 38 6.2. Application Programming Interfaces . . . . . . . . . . . 39
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 38 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 39
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 39 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 40
7.2. Cookie policy . . . . . . . . . . . . . . . . . . . . . . 40 7.2. Cookie policy . . . . . . . . . . . . . . . . . . . . . . 40
7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 40 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 40 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 41 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 42
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 42
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 42 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 43
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 43 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 44
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 44 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 44
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 44 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 45
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 45 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 45
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 45 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 46
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 45 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 46
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 46 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 47
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 46 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 47
8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 46 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 47
8.8.6. Top-level requests with "unsafe" methods . . . . . . 47 8.8.6. Top-level requests with "unsafe" methods . . . . . . 48
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 49
9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 48 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 49
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 48 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 49
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 49 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Normative References . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . 51 10.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 53 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 54
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 53 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 54
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 53 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 54
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 54 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 55
A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 54 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 55
A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 55 A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 56
A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 55 A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 56
A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 55 A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 56
A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 56 A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 57
A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 56 A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 6, line 50 skipping to change at page 6, line 50
"top-level browsing context", and "WorkerGlobalScope" are defined in "top-level browsing context", and "WorkerGlobalScope" are defined in
[HTML]. [HTML].
"Service Workers" are defined in the Service Workers specification "Service Workers" are defined in the Service Workers specification
[SERVICE-WORKERS]. [SERVICE-WORKERS].
The term "origin", the mechanism of deriving an origin from a URI, The term "origin", the mechanism of deriving an origin from a URI,
and the "the same" matching algorithm for origins are defined in and the "the same" matching algorithm for origins are defined in
[RFC6454]. [RFC6454].
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as "Safe" HTTP methods include GET, HEAD, OPTIONS, and TRACE, as defined
defined in Section 9.2.1 of [HTTPSEM]. in Section 9.2.1 of [HTTPSEM].
A domain's "public suffix" is the portion of a domain that is A domain's "public suffix" is the portion of a domain that is
controlled by a public registry, such as "com", "co.uk", and controlled by a public registry, such as "com", "co.uk", and
"pvt.k12.wy.us". A domain's "registrable domain" is the domain's "pvt.k12.wy.us". A domain's "registrable domain" is the domain's
public suffix plus the label to its left. That is, for public suffix plus the label to its left. That is, for
"https://www.site.example", the public suffix is "example", and the https://www.site.example, the public suffix is example, and the
registrable domain is "site.example". Whenever possible, user agents registrable domain is site.example. Whenever possible, user agents
SHOULD use an up-to-date public suffix list, such as the one SHOULD use an up-to-date public suffix list, such as the one
maintained by the Mozilla project at [PSL]. maintained by the Mozilla project at [PSL].
The term "request", as well as a request's "client", "current url", The term "request", as well as a request's "client", "current url",
"method", "target browsing context", and "url list", are defined in "method", "target browsing context", and "url list", are defined in
[FETCH]. [FETCH].
The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set
and retrieve cookies, such as a web browser API that exposes cookies and retrieve cookies, such as a web browser API that exposes cookies
to scripts. to scripts.
skipping to change at page 7, line 49 skipping to change at page 7, line 49
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 SHOULD NOT fold multiple Set-Cookie header fields into
a single header field. The usual mechanism for folding HTTP headers a single header field. The usual mechanism for folding HTTP headers
fields (i.e., as defined in Section 5.3 of [HTTPSEM]) might change fields (i.e., as defined in Section 5.3 of [HTTPSEM]) might change
the semantics of the Set-Cookie header field because the %x2C (",") the semantics of the Set-Cookie header field because the %x2C (",")
character is used by Set-Cookie in a way that conflicts with such character is used by Set-Cookie in a way that conflicts with such
folding. folding.
User agents MAY ignore Set-Cookie header fieldss 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"
named SID with the value 31d4d96e407aad42. The user agent then named SID with the value 31d4d96e407aad42. The user agent then
returns the session identifier in subsequent requests. returns the session identifier in subsequent requests.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
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)
[RFC2818]). [RFC2818]).
Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's
confidentiality. An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details).
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.
4.1.2.7. The SameSite Attribute 4.1.2.7. The SameSite Attribute
The "SameSite" attribute limits the scope of the cookie such that it The "SameSite" attribute limits the scope of the cookie such that it
will only be attached to requests if those requests are same-site, as will only be attached to requests if those requests are same-site, as
defined by the algorithm in Section 5.2. For example, requests for defined by the algorithm in Section 5.2. For example, requests for
"https://site.example/sekrit-image" will attach same-site cookies if https://site.example/sekrit-image will attach same-site cookies if
and only if initiated from a context whose "site for cookies" is an and only if initiated from a context whose "site for cookies" is an
origin with a scheme and registered domain of "https" and origin with a scheme and registered domain of "https" and
"site.example" respectively. "site.example" respectively.
If the "SameSite" attribute's value is "Strict", the cookie will only If the "SameSite" attribute's value is "Strict", the cookie will only
be sent along with "same-site" requests. If the value is "Lax", the be sent along with "same-site" requests. If the value is "Lax", the
cookie will be sent with same-site requests, and with "cross-site" cookie will be sent with same-site requests, and with "cross-site"
top-level navigations, as described in Section 5.4.7.1. If the value top-level navigations, as described in Section 5.4.7.1. If the value
is "None", the cookie will be sent with same-site and cross-site is "None", the cookie will be sent with same-site and cross-site
requests. If the "SameSite" attribute's value is something other requests. If the "SameSite" attribute's value is something other
skipping to change at page 15, line 8 skipping to change at page 14, line 50
confidence in a backwards-compatible way, two common sets of confidence in a backwards-compatible way, two common sets of
requirements can be inferred from the first few characters of the requirements can be inferred from the first few characters of the
cookie's name. cookie's name.
The normative requirements for the prefixes described below are The normative requirements for the prefixes described below are
detailed in the storage model algorithm defined in Section 5.5. detailed in the storage model algorithm defined in Section 5.5.
4.1.3.1. The "__Secure-" Prefix 4.1.3.1. The "__Secure-" Prefix
If a cookie's name begins with a case-sensitive match for the string If a cookie's name begins with a case-sensitive match for the string
"__Secure-", then the cookie will have been set with a "Secure" __Secure-, then the cookie will have been set with a Secure
attribute. attribute.
For example, the following "Set-Cookie" header field would be For example, the following Set-Cookie header field would be rejected
rejected by a conformant user agent, as it does not have a "Secure" by a conformant user agent, as it does not have a Secure attribute.
attribute.
Set-Cookie: __Secure-SID=12345; Domain=site.example Set-Cookie: __Secure-SID=12345; Domain=site.example
Whereas the following "Set-Cookie" header field would be accepted: Whereas the following Set-Cookie header field would be accepted if
set from a secure origin (e.g. "https://site.example/"), and rejected
otherwise:
Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure
4.1.3.2. The "__Host-" Prefix 4.1.3.2. The "__Host-" Prefix
If a cookie's name begins with a case-sensitive match for the string If a cookie's name begins with a case-sensitive match for the string
"__Host-", then the cookie will have been set with a "Secure" __Host-, then the cookie will have been set with a Secure attribute,
attribute, a "Path" attribute with a value of "/", and no "Domain" a Path attribute with a value of /, and no Domain attribute.
attribute.
This combination yields a cookie that hews as closely as a cookie can This combination yields a cookie that hews as closely as a cookie can
to treating the origin as a security boundary. The lack of a to treating the origin as a security boundary. The lack of a Domain
"Domain" attribute ensures that the cookie's "host-only-flag" is attribute ensures that the cookie's host-only-flag is true, locking
true, locking the cookie to a particular host, rather than allowing the cookie to a particular host, rather than allowing it to span
it to span subdomains. Setting the "Path" to "/" means that the subdomains. Setting the Path to / means that the cookie is effective
cookie is effective for the entire host, and won't be overridden for for the entire host, and won't be overridden for specific paths. The
specific paths. The "Secure" attribute ensures that the cookie is Secure attribute ensures that the cookie is unaltered by non-secure
unaltered by non-secure origins, and won't span protocols. origins, and won't span protocols.
Ports are the only piece of the origin model that "__Host-" cookies Ports are the only piece of the origin model that __Host- cookies
continue to ignore. continue to ignore.
For example, the following cookies would always be rejected: For example, the following cookies would always be rejected:
Set-Cookie: __Host-SID=12345 Set-Cookie: __Host-SID=12345
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=/
skipping to change at page 21, line 27 skipping to change at page 21, line 27
For documents which are displayed in nested browsing contexts, we For documents which are displayed in nested browsing contexts, we
need to audit the origins of each of a document's ancestor browsing need to audit the origins of each of a document's ancestor browsing
contexts' active documents in order to account for the "multiple- contexts' active documents in order to account for the "multiple-
nested scenarios" described in Section 4 of [RFC7034]. A document's nested scenarios" described in Section 4 of [RFC7034]. A document's
"site for cookies" is the top-level origin if and only if the top- "site for cookies" is the top-level origin if and only if the top-
level origin is same-site with the document's origin, and with each level origin is same-site with the document's origin, and with each
of the document's ancestor documents' origins. Otherwise its "site of the document's ancestor documents' origins. Otherwise its "site
for cookies" is an origin set to an opaque origin. for cookies" is an origin set to an opaque 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 browsing
browsing context's top-level browsing context. context's top-level browsing context.
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.
3. Let "documents" be a list containing "document" and each of 3. Let documents be a list containing document and each of
"document"'s ancestor browsing contexts' active documents. document's ancestor browsing contexts' active documents.
4. For each "item" in "documents": 4. For each item in documents:
1. Let "origin" be the origin of "item"'s URI if "item"'s 1. Let origin be the origin of item's URI if item's sandboxed
sandboxed origin browsing context flag is set, and "item"'s origin browsing context flag is set, and item's origin
origin otherwise. otherwise.
2. If "origin" is not same-site with "top-origin", return an 2. If origin is not same-site with top-origin, return an origin
origin set to an opaque origin. set to an opaque origin.
5. Return "top-origin". 5. Return top-origin.
5.2.2. Worker-based requests 5.2.2. Worker-based requests
Worker-driven requests aren't as clear-cut as document-driven Worker-driven requests aren't as clear-cut as document-driven
requests, as there isn't a clear link between a top-level browsing requests, as there isn't a clear link between a top-level browsing
context and a worker. This is especially true for Service Workers context and a worker. This is especially true for Service Workers
[SERVICE-WORKERS], which may execute code in the background, without [SERVICE-WORKERS], which may execute code in the background, without
any document visible at all. any document visible at all.
Note: The descriptions below assume that workers must be same-origin Note: The descriptions below assume that workers must be same-origin
with the documents that instantiate them. If this invariant changes, with the documents that instantiate them. If this invariant changes,
we'll need to take the worker's script's URI into account when we'll need to take the worker's script's URI into account when
determining their status. determining their status.
5.2.2.1. Dedicated and Shared Workers 5.2.2.1. Dedicated and Shared Workers
Dedicated workers are simple, as each dedicated worker is bound to Dedicated workers are simple, as each dedicated worker is bound to
one and only one document. Requests generated from a dedicated one and only one document. Requests generated from a dedicated
worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define worker (via importScripts, XMLHttpRequest, fetch(), etc) define their
their "site for cookies" as that document's "site for cookies". "site for cookies" as that document's "site for cookies".
Shared workers may be bound to multiple documents at once. As it is Shared workers may be bound to multiple documents at once. As it is
quite possible for those documents to have distinct "site for quite possible for those documents to have distinct "site for
cookies" values, the worker's "site for cookies" will be an origin cookies" values, the worker's "site for cookies" will be an origin
set to an opaque origin in cases where the values are not all same- set to an opaque origin in cases where the values are not all same-
site with the worker's origin, and the worker's origin in cases where site with the worker's origin, and the worker's origin in cases where
the values agree. the values agree.
Given a WorkerGlobalScope ("worker"), the following algorithm returns Given a WorkerGlobalScope (worker), the following algorithm returns
its "site for cookies": its "site for cookies":
1. Let "site" be "worker"'s origin. 1. Let site be worker's origin.
2. For each "document" in "worker"'s Documents: 2. For each document in worker's Documents:
1. Let "document-site" be "document"'s "site for cookies" (as 1. Let document-site be document's "site for cookies" (as
defined in Section 5.2.1). defined in Section 5.2.1).
2. If "document-site" is not same-site with "site", return an 2. If document-site is not same-site with site, return an origin
origin set to an opaque origin. set to an opaque origin.
3. Return "site". 3. Return site.
5.2.2.2. Service Workers 5.2.2.2. Service Workers
Service Workers are more complicated, as they act as a completely Service Workers are more complicated, as they act as a completely
separate execution context with only tangential relationship to the separate execution context with only tangential relationship to the
Document which registered them. Document which registered them.
Requests which simply pass through a Service Worker will be handled Requests which simply pass through a Service Worker will be handled
as described above: the request's client will be the Document or as described above: the request's client will be the Document or
Worker which initiated the request, and its "site for cookies" will Worker which initiated the request, and its "site for cookies" will
be those defined in Section 5.2.1 and Section 5.2.2.1 be those defined in Section 5.2.1 and Section 5.2.2.1
Requests which are initiated by the Service Worker itself (via a Requests which are initiated by the Service Worker itself (via a
direct call to "fetch()", for instance), on the other hand, will have direct call to fetch(), for instance), on the other hand, will have a
a client which is a ServiceWorkerGlobalScope. Its "site for cookies" client which is a ServiceWorkerGlobalScope. Its "site for cookies"
will be the Service Worker's URI's origin. will be the Service Worker's URI's origin.
Given a ServiceWorkerGlobalScope ("worker"), the following algorithm Given a ServiceWorkerGlobalScope (worker), the following algorithm
returns its "site for cookies": returns its "site for cookies":
1. Return "worker"'s origin. 1. Return worker's origin.
5.3. Ignoring Set-Cookie Header Fields 5.3. Ignoring Set-Cookie Header Fields
User agents MAY ignore Set-Cookie header fields contained in User agents MAY ignore Set-Cookie header fields contained in
responses with 100-level status codes or based on its cookie policy responses with 100-level status codes or based on its cookie policy
(see Section 7.2). (see Section 7.2).
All other Set-Cookie header fields SHOULD be processed according to All other Set-Cookie header fields SHOULD be processed according to
Section 5.4. That is, Set-Cookie header fields contained in Section 5.4. That is, Set-Cookie header fields contained in
responses with non-100-level status codes (including those in responses with non-100-level status codes (including those in
skipping to change at page 24, line 7 skipping to change at page 24, line 7
Section 4.1. For example, the algorithm strips leading and trailing Section 4.1. For example, the algorithm strips leading and trailing
whitespace from the cookie name and value (but maintains internal whitespace from the cookie name and value (but maintains internal
whitespace), whereas the grammar in Section 4.1 forbids whitespace in whitespace), whereas the grammar in Section 4.1 forbids whitespace in
these positions. In addition, the algorithm below accommodates some these positions. In addition, the algorithm below accommodates some
characters that are not cookie-octets according to the grammar in characters that are not cookie-octets according to the grammar in
Section 4.1. User agents use this algorithm so as to interoperate Section 4.1. User agents use this algorithm so as to interoperate
with servers that do not follow the recommendations in Section 4. with servers that do not follow the recommendations in Section 4.
NOTE: As set-cookie-string may originate from a non-HTTP API, it is NOTE: As set-cookie-string may originate from a non-HTTP API, it is
not guaranteed to be free of CTL characters, so this algorithm not guaranteed to be free of CTL characters, so this algorithm
handles them explicitly. handles them explicitly. Horizontal tab (%x09) is excluded from the
CTL characters that lead to set-cookie-string rejection, as it is
considered whitespace, which is handled separately.
A user agent MUST use an algorithm equivalent to the following A user agent MUST use an algorithm equivalent to the following
algorithm to parse a set-cookie-string: algorithm to parse a set-cookie-string:
1. If the set-cookie-string contains a %x0D (CR), %x0A (LF), or %x00 1. If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F
(NUL) octet, then set the set-cookie-string equal to all the character (CTL characters excluding HTAB): Abort these steps and
characters of set-cookie-string up to, but not including, the ignore the set-cookie-string entirely.
first such octet.
2. If the set-cookie-string contains a %x00-1F / %x7F (CTL)
character: Abort these steps and ignore the set-cookie-string
entirely.
3. If the set-cookie-string contains a %x3B (";") character: 2. If the set-cookie-string contains a %x3B (";") character:
1. The name-value-pair string consists of the characters up to, 1. The name-value-pair string consists of the characters up to,
but not including, the first %x3B (";"), and the unparsed- but not including, the first %x3B (";"), and the unparsed-
attributes consist of the remainder of the set-cookie-string attributes consist of the remainder of the set-cookie-string
(including the %x3B (";") in question). (including the %x3B (";") in question).
Otherwise: Otherwise:
1. The name-value-pair string consists of all the characters 1. The name-value-pair string consists of all the characters
contained in the set-cookie-string, and the unparsed- contained in the set-cookie-string, and the unparsed-
attributes is the empty string. attributes is the empty string.
4. If the name-value-pair string lacks a %x3D ("=") character, then 3. If the name-value-pair string lacks a %x3D ("=") character, then
the name string is empty, and the value string is the value of the name string is empty, and the value string is the value of
name-value-pair. name-value-pair.
Otherwise, the name string consists of the characters up to, but Otherwise, the name string consists of the characters up to, but
not including, the first %x3D ("=") character, and the (possibly not including, the first %x3D ("=") character, and the (possibly
empty) value string consists of the characters after the first empty) value string consists of the characters after the first
%x3D ("=") character. %x3D ("=") character.
5. Remove any leading or trailing WSP characters from the name 4. Remove any leading or trailing WSP characters from the name
string and the value string. string and the value string.
5. If the sum of the lengths of the name string and the value string
is more than 4096 octets, abort these steps and ignore the set-
cookie-string entirely.
6. The cookie-name is the name string, and the cookie-value is the 6. The cookie-name is the name string, and the cookie-value is the
value string. value string.
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse the unparsed-attributes: algorithm to parse the unparsed-attributes:
1. If the unparsed-attributes string is empty, skip the rest of 1. If the unparsed-attributes string is empty, skip the rest of
these steps. these steps.
2. Discard the first character of the unparsed-attributes (which 2. Discard the first character of the unparsed-attributes (which
skipping to change at page 25, line 39 skipping to change at page 25, line 39
character. character.
Otherwise: Otherwise:
1. The attribute-name string consists of the entire cookie-av 1. The attribute-name string consists of the entire cookie-av
string, and the attribute-value string is empty. string, and the attribute-value string is empty.
5. Remove any leading or trailing WSP characters from the attribute- 5. Remove any leading or trailing WSP characters from the attribute-
name string and the attribute-value string. name string and the attribute-value string.
6. Process the attribute-name and attribute-value according to the 6. If the attribute-value is longer than 1024 octets, ignore the
cookie-av string and return to Step 1 of this algorithm.
7. Process the attribute-name and attribute-value according to the
requirements in the following subsections. (Notice that requirements in the following subsections. (Notice that
attributes with unrecognized attribute-names are ignored.) attributes with unrecognized attribute-names are ignored.)
7. Return to Step 1 of this algorithm. 8. Return to Step 1 of this algorithm.
When the user agent finishes parsing the set-cookie-string, the user When the user agent finishes parsing the set-cookie-string, the user
agent is said to "receive a cookie" from the request-uri with name agent is said to "receive a cookie" from the request-uri with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list. (See Section 5.5 for additional requirements triggered by list. (See Section 5.5 for additional requirements triggered by
receiving a cookie.) receiving a cookie.)
5.4.1. The Expires Attribute 5.4.1. The Expires Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
skipping to change at page 27, line 5 skipping to change at page 27, line 5
seconds. seconds.
5. Append an attribute to the cookie-attribute-list with an 5. Append an attribute to the cookie-attribute-list with an
attribute-name of Max-Age and an attribute-value of expiry-time. attribute-name of Max-Age and an attribute-value of expiry-time.
5.4.3. The Domain Attribute 5.4.3. The Domain Attribute
If the attribute-name case-insensitively matches the string "Domain", If the attribute-name case-insensitively matches the string "Domain",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
1. If the attribute-value is empty, the behavior is undefined. 1. Let cookie-domain be the attribute-value.
However, the user agent SHOULD ignore the cookie-av entirely.
2. If the first character of the attribute-value string is %x2E
("."):
1. Let cookie-domain be the attribute-value without the leading
%x2E (".") character.
Otherwise:
1. Let cookie-domain be the entire attribute-value. 2. If cookie-domain starts with %x2E ("."), let cookie-domain be
cookie-domain without its leading %x2E (".").
3. Convert the cookie-domain to lower case. 3. Convert the cookie-domain to lower case.
4. Append an attribute to the cookie-attribute-list with an 4. Append an attribute to the cookie-attribute-list with an
attribute-name of Domain and an attribute-value of cookie-domain. attribute-name of Domain and an attribute-value of cookie-domain.
5.4.4. The Path Attribute 5.4.4. The Path Attribute
If the attribute-name case-insensitively matches the string "Path", If the attribute-name case-insensitively matches the string "Path",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
skipping to change at page 28, line 10 skipping to change at page 27, line 50
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"HttpOnly", the user agent MUST append an attribute to the cookie- "HttpOnly", the user agent MUST append an attribute to the cookie-
attribute-list with an attribute-name of HttpOnly and an empty attribute-list with an attribute-name of HttpOnly and an empty
attribute-value. attribute-value.
5.4.7. The SameSite Attribute 5.4.7. The SameSite Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"SameSite", the user agent MUST process the cookie-av as follows: "SameSite", the user agent MUST process the cookie-av as follows:
1. Let "enforcement" be "Default". 1. Let enforcement be "Default".
2. If cookie-av's attribute-value is a case-insensitive match for 2. If cookie-av's attribute-value is a case-insensitive match for
"None", set "enforcement" to "None". "None", set enforcement to "None".
3. If cookie-av's attribute-value is a case-insensitive match for 3. If cookie-av's attribute-value is a case-insensitive match for
"Strict", set "enforcement" to "Strict". "Strict", set enforcement to "Strict".
4. If cookie-av's attribute-value is a case-insensitive match for 4. If cookie-av's attribute-value is a case-insensitive match for
"Lax", set "enforcement" to "Lax". "Lax", set enforcement to "Lax".
5. Append an attribute to the cookie-attribute-list with an 5. Append an attribute to the cookie-attribute-list with an
attribute-name of "SameSite" and an attribute-value of attribute-name of "SameSite" and an attribute-value of
"enforcement". enforcement.
5.4.7.1. "Strict" and "Lax" enforcement 5.4.7.1. "Strict" and "Lax" enforcement
Same-site cookies in "Strict" enforcement mode will not be sent along Same-site cookies in "Strict" enforcement mode will not be sent along
with top-level navigations which are triggered from a cross-site with top-level navigations which are triggered from a cross-site
document context. As discussed in Section 8.8.2, this might or might document context. As discussed in Section 8.8.2, this might or might
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 [HTTPSEM] sense) HTTP level navigations which use a "safe" (in the [HTTPSEM] 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 [HTTPSEM]); GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTPSEM]);
in these cases, a request's "safe"ness is determined based on the in these cases, a request's "safe"ness is determined based on the
method of the current redirect hop.) method 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 When possible, developers should use a session management mechanism
such as that described in Section 8.8.2 to mitigate the risk of CSRF such as that described in Section 8.8.2 to mitigate the risk of CSRF
more completely. more completely.
5.4.7.2. "Lax-Allowing-Unsafe" enforcement 5.4.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.6.3. (All cookies, of the retrieval algorithm in Section 5.6.3. (All cookies,
regardless of "SameSite" enforcement mode, may be set for top-level regardless of SameSite enforcement mode, may be set for top-level
navigations, regardless of HTTP request method, as specified in navigations, regardless of HTTP request method, as specified in
Section 5.5.) Section 5.5.)
"Lax-allowing-unsafe" is not a distinct value of the "SameSite" "Lax-allowing-unsafe" is not a distinct value of the SameSite
attribute. Rather, user agents MAY apply "Lax-allowing-unsafe" attribute. Rather, user agents MAY apply "Lax-allowing-unsafe"
enforcement only to cookies that did not explicitly specify a enforcement only to cookies that did not explicitly specify a
"SameSite" attribute (i.e., those whose same-site-flag was set to SameSite attribute (i.e., those whose same-site-flag was set to
"Default" by default). To limit the scope of this compatibility "Default" by default). To limit the scope of this compatibility
mode, user agents which apply "Lax-allowing-unsafe" enforcement mode, user agents which apply "Lax-allowing-unsafe" enforcement
SHOULD restrict the enforcement to cookies which were created SHOULD restrict the enforcement to cookies which were created
recently. Deployment experience has shown a cookie age of 2 minutes recently. Deployment experience has shown a cookie age of 2 minutes
or less to be a reasonable limit. or less to be a reasonable limit.
If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST
apply the following modification to the retrieval algorithm defined apply the following modification to the retrieval algorithm defined
in Section 5.6.3: in Section 5.6.3:
skipping to change at page 30, line 22 skipping to change at page 30, line 15
When the user agent "receives a cookie" from a request-uri with name When the user agent "receives a cookie" from a request-uri with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list, the user agent MUST process the cookie as follows: list, the user agent MUST process the cookie as follows:
1. A user agent MAY ignore a received cookie in its entirety. See 1. A user agent MAY ignore a received cookie in its entirety. See
Section 5.3. Section 5.3.
2. If cookie-name is empty and cookie-value is empty, abort these 2. If cookie-name is empty and cookie-value is empty, abort these
steps and ignore the cookie entirely. steps and ignore the cookie entirely.
3. If the cookie-name or the cookie-value contains a %x00-1F / %x7F 3. If the cookie-name or the cookie-value contains a %x00-08 /
(CTL) character, abort these steps and ignore the cookie %x0A-1F / %x7F character (CTL characters excluding HTAB), abort
these steps and ignore the cookie entirely.
4. If the sum of the lengths of cookie-name and cookie-value is
more than 4096 octets, abort these steps and ignore the cookie
entirely. entirely.
4. Create a new cookie with name cookie-name, value cookie-value. 5. Create a new cookie with name cookie-name, value cookie-value.
Set the creation-time and the last-access-time to the current Set the creation-time and the last-access-time to the current
date and time. date and time.
5. If the cookie-attribute-list contains an attribute with an 6. If the cookie-attribute-list contains an attribute with an
attribute-name of "Max-Age": attribute-name of "Max-Age":
1. Set the cookie's persistent-flag to true. 1. Set the cookie's persistent-flag to true.
2. Set the cookie's expiry-time to attribute-value of the last 2. Set the cookie's expiry-time to attribute-value of the last
attribute in the cookie-attribute-list with an attribute- attribute in the cookie-attribute-list with an attribute-
name of "Max-Age". name of "Max-Age".
Otherwise, if the cookie-attribute-list contains an attribute Otherwise, if the cookie-attribute-list contains an attribute
with an attribute-name of "Expires" (and does not contain an with an attribute-name of "Expires" (and does not contain an
skipping to change at page 31, line 8 skipping to change at page 31, line 5
attribute in the cookie-attribute-list with an attribute- attribute in the cookie-attribute-list with an attribute-
name of "Expires". name of "Expires".
Otherwise: Otherwise:
1. Set the cookie's persistent-flag to false. 1. Set the cookie's persistent-flag to false.
2. Set the cookie's expiry-time to the latest representable 2. Set the cookie's expiry-time to the latest representable
date. date.
6. If the cookie-attribute-list contains an attribute with an 7. If the cookie-attribute-list contains an attribute with an
attribute-name of "Domain": attribute-name of "Domain":
1. Let the domain-attribute be the attribute-value of the last 1. Let the domain-attribute be the attribute-value of the last
attribute in the cookie-attribute-list with an attribute- attribute in the cookie-attribute-list with both an
name of "Domain". attribute-name of "Domain" and an attribute-value whose
length is no more than 1024 octets. (Note that a leading
%x2E ("."), if present, is ignored even though that
character is not permitted, but a trailing %x2E ("."), if
present, will cause the user agent to ignore the attribute.)
Otherwise: Otherwise:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
7. If the user agent is configured to reject "public suffixes" and 8. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix: the domain-attribute is a public suffix:
1. If the domain-attribute is identical to the canonicalized 1. If the domain-attribute is identical to the canonicalized
request-host: request-host:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
Otherwise: Otherwise:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
NOTE: This step prevents "attacker.example" from disrupting the NOTE: This step prevents attacker.example from disrupting the
integrity of "site.example" by setting a cookie with a Domain integrity of site.example by setting a cookie with a Domain
attribute of "example". attribute of "example".
8. If the domain-attribute is non-empty: 9. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If the canonicalized request-host does not domain-match the
domain-attribute: domain-attribute:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to false. 1. Set the cookie's host-only-flag to false.
2. Set the cookie's domain to the domain-attribute. 2. Set the cookie's domain to the domain-attribute.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to true. 1. Set the cookie's host-only-flag to true.
2. Set the cookie's domain to the canonicalized request-host. 2. Set the cookie's domain to the canonicalized request-host.
9. If the cookie-attribute-list contains an attribute with an 10. If the cookie-attribute-list contains an attribute with an
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 an value of the last attribute in the cookie-attribute-list with
attribute-name of "Path". Otherwise, set the cookie's path to both an attribute-name of "Path" and an attribute-value whose
the default-path of the request-uri. length is no more than 1024 octets. Otherwise, set the cookie's
path to the default-path of the request-uri.
10. If the cookie-attribute-list contains an attribute with an 11. 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.
11. If the scheme component of the request-uri does not denote a 12. If the scheme component of the request-uri does not denote a
"secure" protocol (as defined by the user agent), and the "secure" protocol (as defined by the user agent), and the
cookie's secure-only-flag is true, then abort these steps and cookie's secure-only-flag is true, then abort these steps and
ignore the cookie entirely. ignore the cookie entirely.
12. If the cookie-attribute-list contains an attribute with an 13. 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.
13. If the cookie was received from a "non-HTTP" API and the 14. 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.
14. If the cookie's secure-only-flag is false, and the scheme 15. If the cookie's secure-only-flag is false, and the scheme
component of request-uri does not denote a "secure" protocol, component of request-uri does not denote a "secure" protocol,
then abort these steps and ignore the cookie entirely if the then abort these steps and ignore the cookie entirely if the
cookie store contains one or more cookies that meet all of the cookie store contains one 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
skipping to change at page 33, line 5 skipping to change at page 33, line 13
of the existing cookie. of the existing cookie.
Note: The path comparison is not symmetric, ensuring only that a Note: The path comparison is not symmetric, ensuring only that a
newly-created, non-secure cookie does not overlay an existing newly-created, non-secure cookie does not overlay an existing
secure cookie, providing some mitigation against cookie-fixing secure cookie, providing some mitigation against cookie-fixing
attacks. That is, given an existing secure cookie named 'a' attacks. That is, given an existing secure cookie named 'a'
with a path of '/login', a non-secure cookie named 'a' could be with a path of '/login', a non-secure cookie named 'a' could be
set for a path of '/' or '/foo', but not for a path of '/login' set for a path of '/' or '/foo', but not for a path of '/login'
or '/login/en'. or '/login/en'.
15. If the cookie-attribute-list contains an attribute with an 16. If the cookie-attribute-list contains an attribute with an
attribute-name of "SameSite", and an attribute-value of attribute-name of "SameSite", and an attribute-value of
"Strict", "Lax", or "None", set the cookie's same-site-flag to "Strict", "Lax", or "None", set the cookie's same-site-flag to
the attribute-value of the last attribute in the cookie- the attribute-value of the last attribute in the cookie-
attribute-list with an attribute-name of "SameSite". Otherwise, attribute-list with an attribute-name of "SameSite". Otherwise,
set the cookie's same-site-flag to "Default". set the cookie's same-site-flag to "Default".
16. If the cookie's "same-site-flag" is not "None": 17. If the cookie's same-site-flag is not "None":
1. If the cookie was received from a "non-HTTP" API, and the 1. If the cookie was received from a "non-HTTP" API, and the
API was called from a browsing context's active document API was called from a browsing context's active document
whose "site for cookies" is not same-site with the top-level whose "site for cookies" is not same-site with the top-level
origin, then abort these steps and ignore the newly created origin, then abort these steps and ignore the newly created
cookie entirely. cookie entirely.
2. If the cookie was received from a "same-site" request (as 2. If the cookie was received from a "same-site" request (as
defined in Section 5.2), skip the remaining substeps and defined in Section 5.2), skip the remaining substeps and
continue processing the cookie. continue processing the cookie.
3. If the cookie was received from a request which is 3. If the cookie was received from a request which is
navigating a top-level browsing context [HTML] (e.g. if the navigating a top-level browsing context [HTML] (e.g. if the
request's "reserved client" is either "null" or an request's "reserved client" is either null or an environment
environment whose "target browsing context" is a top-level whose "target browsing context" is a top-level browing
browing context), skip the remaining substeps and continue context), skip the remaining substeps and continue
processing the cookie. processing the cookie.
Note: Top-level navigations can create a cookie with any Note: Top-level navigations can create a cookie with any
"SameSite" value, even if the new cookie wouldn't have been SameSite value, even if the new cookie wouldn't have been
sent along with the request had it already existed prior to sent along with the request had it already existed prior to
the navigation. the navigation.
4. Abort these steps and ignore the newly created cookie 4. Abort these steps and ignore the newly created cookie
entirely. entirely.
17. If the cookie's "same-site-flag" is "None", abort these steps 18. If the cookie's "same-site-flag" is "None", abort these steps
and ignore the cookie entirely unless the cookie's secure-only- and ignore the cookie entirely unless the cookie's secure-only-
flag is true. flag is true.
18. If the cookie-name begins with a case-sensitive match for the 19. If the cookie-name begins with a case-sensitive match for the
string "__Secure-", abort these steps and ignore the cookie string "__Secure-", abort these steps and ignore the cookie
entirely unless the cookie's secure-only-flag is true. entirely unless the cookie's secure-only-flag is true.
19. If the cookie-name begins with a case-sensitive match for the 20. If the cookie-name begins with a case-sensitive match for the
string "__Host-", abort these steps and ignore the cookie string "__Host-", abort these steps and ignore the cookie
entirely unless the cookie meets all the following criteria: entirely unless the cookie meets all the following criteria:
1. The cookie's secure-only-flag is true. 1. The cookie's secure-only-flag is true.
2. The cookie's host-only-flag is true. 2. The cookie's host-only-flag is true.
3. The cookie-attribute-list contains an attribute with an 3. The cookie-attribute-list contains an attribute with an
attribute-name of "Path", and the cookie's path is "/". attribute-name of "Path", and the cookie's path is /.
20. If the cookie store contains a cookie with the same name, 21. If the cookie store contains a cookie with the same name,
domain, host-only-flag, and path as the newly-created cookie: domain, host-only-flag, and path as the newly-created cookie:
1. Let old-cookie be the existing cookie with the same name, 1. Let old-cookie be the existing cookie with the same name,
domain, host-only-flag, and path as the newly-created domain, host-only-flag, and path as the newly-created
cookie. (Notice that this algorithm maintains the invariant cookie. (Notice that this algorithm maintains the invariant
that there is at most one such cookie.) that there is at most one such cookie.)
2. If the newly-created cookie was received from a "non-HTTP" 2. If the newly-created cookie was received from a "non-HTTP"
API and the old-cookie's http-only-flag is true, abort these API and the old-cookie's http-only-flag is true, abort these
steps and ignore the newly created cookie entirely. steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly-created cookie to 3. Update the creation-time of the newly-created cookie to
match the creation-time of the old-cookie. match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store. 4. Remove the old-cookie from the cookie store.
21. Insert the newly-created cookie into the cookie store. 22. Insert the newly-created cookie into the cookie store.
A cookie is "expired" if the cookie has an expiry date in the past. A cookie is "expired" if the cookie has an expiry date in the past.
The user agent MUST evict all expired cookies from the cookie store The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store. if, at any time, an expired cookie exists in the cookie store.
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the number of cookies sharing a domain field exceeds cookie store if the number of cookies sharing a domain field exceeds
some implementation-defined upper bound (such as 50 cookies). some implementation-defined upper bound (such as 50 cookies).
skipping to change at page 38, line 13 skipping to change at page 38, line 30
octets is valid UTF-8. octets is valid UTF-8.
6. Implementation Considerations 6. Implementation Considerations
6.1. Limits 6.1. Limits
Practical user agent implementations have limits on the number and Practical user agent implementations have limits on the number and
size of cookies that they can store. General-use user agents SHOULD size of cookies that they can store. General-use user agents SHOULD
provide each of the following minimum capabilities: provide each of the following minimum capabilities:
* At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie's name, value, and attributes).
* At least 50 cookies per domain. * At least 50 cookies per domain.
* At least 3000 cookies total. * At least 3000 cookies total.
User agents MAY limit the maximum number of cookies they store, and
may evict any cookie at any time (whether at the request of the user
or due to implementation limitations).
Note that a limit on the maximum number of cookies also limits the
total size of the stored cookies, due to the length limits which MUST
be enforced in Section 5.4.
Servers SHOULD use as few and as small cookies as possible to avoid Servers SHOULD use as few and as small cookies as possible to avoid
reaching these implementation limits and to minimize network reaching these implementation limits and to minimize network
bandwidth due to the Cookie header field being included in every bandwidth due to the Cookie header field being included in every
request. request.
Servers SHOULD gracefully degrade if the user agent fails to return Servers SHOULD gracefully degrade if the user agent fails to return
one or more cookies in the Cookie header field because the user agent one or more cookies in the Cookie header field because the user agent
might evict any cookie at any time on orders from the user. might evict any cookie at any time.
6.2. Application Programming Interfaces 6.2. Application Programming Interfaces
One reason the Cookie and Set-Cookie header fields use such esoteric One reason the Cookie and Set-Cookie header fields use such esoteric
syntax is that many platforms (both in servers and user agents) syntax is that many platforms (both in servers and user agents)
provide a string-based application programming interface (API) to provide a string-based application programming interface (API) to
cookies, requiring application-layer programmers to generate and cookies, requiring application-layer programmers to generate and
parse the syntax used by the Cookie and Set-Cookie header fields, parse the syntax used by the Cookie and Set-Cookie header fields,
which many programmers have done incorrectly, resulting in which many programmers have done incorrectly, resulting in
interoperability problems. interoperability problems.
skipping to change at page 39, line 37 skipping to change at page 40, line 23
another site that contains content from the same third party, the another site that contains content from the same third party, the
third party can track the user between the two sites. third party can track the user between the two sites.
Given this risk to user privacy, some user agents restrict how third- Given this risk to user privacy, some user agents restrict how third-
party cookies behave, and those restrictions vary widly. For party cookies behave, and those restrictions vary widly. For
instance, user agents might block third-party cookies entirely by instance, user agents might block third-party cookies entirely by
refusing to send Cookie header fields or process Set-Cookie header refusing to send Cookie header fields or process Set-Cookie header
fields during third-party requests. They might take a less draconian fields during third-party requests. They might take a less draconian
approach by partitioning cookies based on the first-party context, approach by partitioning cookies based on the first-party context,
sending one set of cookies to a given third party in one first-party sending one set of cookies to a given third party in one first-party
context, and another to the same third party in another. context, and another to the same third party in another. Or they
might even allow some third-party cookies but block others depending
on user-agent cookie policy or user controls.
This document grants user agents wide latitude to experiment with This document grants user agents wide latitude to experiment with
third-party cookie policies that balance the privacy and third-party cookie policies that balance the privacy and
compatibility needs of their users. However, this document does not compatibility needs of their users. However, this document does not
endorse any particular third-party cookie policy. endorse any particular third-party cookie policy.
Third-party cookie blocking policies are often ineffective at Third-party cookie blocking policies are often ineffective at
achieving their privacy goals if servers attempt to work around their achieving their privacy goals if servers attempt to work around their
restrictions to track users. In particular, two collaborating restrictions to track users. In particular, two collaborating
servers can often track users without using cookies at all by servers can often track users without using cookies at all by
skipping to change at page 44, line 37 skipping to change at page 45, line 27
An active network attacker can also inject cookies into the Cookie An active network attacker can also inject cookies into the Cookie
header field sent to https://site.example/ by impersonating a header field sent to https://site.example/ by impersonating a
response from http://site.example/ and injecting a Set-Cookie header response from http://site.example/ and injecting a Set-Cookie header
field. The HTTPS server at site.example will be unable to field. The HTTPS server at site.example will be unable to
distinguish these cookies from cookies that it set itself in an HTTPS distinguish these cookies from cookies that it set itself in an HTTPS
response. An active network attacker might be able to leverage this response. An active network attacker might be able to leverage this
ability to mount an attack against site.example even if site.example ability to mount an attack against site.example even if site.example
uses HTTPS exclusively. uses HTTPS exclusively.
Servers can partially mitigate these attacks by encrypting and Servers can partially mitigate these attacks by encrypting and
signing the contents of their cookies. However, using cryptography signing the contents of their cookies, or by naming the cookie with
does not mitigate the issue completely because an attacker can replay the __Secure- prefix. However, using cryptography does not mitigate
a cookie he or she received from the authentic site.example server in the issue completely because an attacker can replay a cookie he or
the user's session, with unpredictable results. she received from the authentic site.example server in the user's
session, with unpredictable results.
Finally, an attacker might be able to force the user agent to delete Finally, an attacker might be able to force the user agent to delete
cookies by storing a large number of cookies. Once the user agent cookies by storing a large number of cookies. Once the user agent
reaches its storage limit, the user agent will be forced to evict reaches its storage limit, the user agent will be forced to evict
some cookies. Servers SHOULD NOT rely upon user agents retaining some cookies. Servers SHOULD NOT rely upon user agents retaining
cookies. cookies.
8.7. Reliance on DNS 8.7. Reliance on DNS
Cookies rely upon the Domain Name System (DNS) for security. If the Cookies rely upon the Domain Name System (DNS) for security. If the
skipping to change at page 45, line 26 skipping to change at page 46, line 23
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
Setting the "SameSite" attribute in "strict" mode provides robust Setting the SameSite attribute in "strict" mode provides robust
defense in depth against CSRF attacks, but has the potential to defense in depth against CSRF attacks, but has the potential to
confuse users unless sites' developers carefully ensure that their confuse users unless sites' developers carefully ensure that their
cookie-based session management systems deal reasonably well with cookie-based session management systems deal reasonably well with
top-level navigations. top-level navigations.
Consider the scenario in which a user reads their email at MegaCorp Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://site.example/". They might expect Inc's webmail provider https://site.example/. They might expect that
that clicking on an emailed link to "https://projects.example/secret/ clicking on an emailed link to https://projects.example/secret/
project" would show them the secret project that they're authorized project would show them the secret project that they're authorized to
to see, but if "https://projects.example" has marked their session see, but if https://projects.example has marked their session cookies
cookies as "SameSite=Strict", then this cross-site navigation won't as SameSite=Strict, then this cross-site navigation won't send them
send them along with the request. "https://projects.example" will along with the request. https://projects.example will render a 404
render a 404 error to avoid leaking secret information, and the user error to avoid leaking secret information, and the user will be quite
will be quite confused. confused.
Developers can avoid this confusion by adopting a session management Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptually system that relies on not one, but two cookies: one conceptually
granting "read" access, another granting "write" access. The latter granting "read" access, another granting "write" access. The latter
could be marked as "SameSite=Strict", and its absence would prompt a could be marked as SameSite=Strict, and its absence would prompt a
reauthentication step before executing any non-idempotent action. reauthentication step before executing any non-idempotent action.
The former could be marked as "SameSite=Lax", in order to allow users The former could be marked as SameSite=Lax, in order to allow users
access to data via top-level navigation, or "SameSite=None", to access to data via top-level navigation, or SameSite=None, to permit
permit access in all contexts (including cross-site embedded access in all contexts (including cross-site embedded contexts).
contexts).
8.8.3. Mashups and Widgets 8.8.3. Mashups and Widgets
The "Lax" and "Strict" values for the "SameSite" attribute are The Lax and Strict values for the SameSite attribute are
inappropriate for some important use-cases. In particular, note that inappropriate for some important use-cases. In particular, note that
content intended for embedding in cross-site contexts (social content intended for embedding in cross-site contexts (social
networking widgets or commenting services, for instance) will not networking widgets or commenting services, for instance) will not
have access to same-site cookies. Cookies which are required in have access to same-site cookies. Cookies which are required in
these situations should be marked with "SameSite=None" to allow these situations should be marked with SameSite=None to allow access
access in cross-site contexts. in cross-site contexts.
Likewise, some forms of Single-Sign-On might require cookie-based Likewise, some forms of Single-Sign-On might require cookie-based
authentication in a cross-site context; these mechanisms will not authentication in a cross-site context; these mechanisms will not
function as intended with same-site cookies and will also require function as intended with same-site cookies and will also require
"SameSite=None". SameSite=None.
8.8.4. Server-controlled 8.8.4. Server-controlled
SameSite cookies in and of themselves don't do anything to address SameSite cookies in and of themselves don't do anything to address
the general privacy concerns outlined in Section 7.1 of [RFC6265]. the general privacy concerns outlined in Section 7.1 of [RFC6265].
The "SameSite" attribute is set by the server, and serves to mitigate The "SameSite" attribute is set by the server, and serves to mitigate
the risk of certain kinds of attacks that the server is worried the risk of certain kinds of attacks that the server is worried
about. The user is not involved in this decision. Moreover, a about. The user is not involved in this decision. Moreover, a
number of side-channels exist which could allow a server to link number of side-channels exist which could allow a server to link
distinct requests even in the absence of cookies (for example, distinct requests even in the absence of cookies (for example,
skipping to change at page 46, line 42 skipping to change at page 47, line 42
8.8.5. Reload navigations 8.8.5. Reload navigations
Requests issued for reloads triggered through user interface elements Requests issued for reloads triggered through user interface elements
(such as a refresh button on a toolbar) are same-site only if the (such as a refresh button on a toolbar) are same-site only if the
reloaded document was originally navigated to via a same-site reloaded document was originally navigated to via a same-site
request. This differs from the handling of other reload navigations, request. This differs from the handling of other reload navigations,
which are always same-site if top-level, since the source browsing which are always same-site if top-level, since the source browsing
context's active document is precisely the document being reloaded. context's active document is precisely the document being reloaded.
This special handling of reloads triggered through a user interface This special handling of reloads triggered through a user interface
element avoids sending "SameSite" cookies on user-initiated reloads element avoids sending SameSite cookies on user-initiated reloads if
if they were withheld on the original navigation (i.e., if the they were withheld on the original navigation (i.e., if the initial
initial navigation were cross-site). If the reload navigation were navigation were cross-site). If the reload navigation were instead
instead considered same-site, and sent all the initially withheld considered same-site, and sent all the initially withheld SameSite
"SameSite" cookies, the security benefits of withholding the cookies cookies, the security benefits of withholding the cookies in the
in the first place would be nullified. This is especially important first place would be nullified. This is especially important given
given that the absence of "SameSite" cookies withheld on a cross-site that the absence of SameSite cookies withheld on a cross-site
navigation request may lead to visible site breakage, prompting the navigation request may lead to visible site breakage, prompting the
user to trigger a reload. user to trigger a reload.
For example, suppose the user clicks on a link from For example, suppose the user clicks on a link from
"https://attacker.example/" to "https://victim.example/". This is a https://attacker.example/ to https://victim.example/. This is a
cross-site request, so "SameSite=Strict" cookies are withheld. cross-site request, so SameSite=Strict cookies are withheld. Suppose
Suppose this causes "https://victim.example/" to appear broken, this causes https://victim.example/ to appear broken, because the
because the site only displays its sensitive content if a particular site only displays its sensitive content if a particular SameSite
"SameSite" cookie is present in the request. The user, frustrated by cookie is present in the request. The user, frustrated by the
the unexpectedly broken site, presses refresh on their browser's unexpectedly broken site, presses refresh on their browser's toolbar.
toolbar. To now consider the reload request same-site and send the To now consider the reload request same-site and send the initially
initially withheld "SameSite" cookie would defeat the purpose of withheld SameSite cookie would defeat the purpose of withholding it
withholding it in the first place, as the reload navigation triggered in the first place, as the reload navigation triggered through the
through the user interface may replay the original (potentially user interface may replay the original (potentially malicious)
malicious) request. Thus, the reload request should be considered request. Thus, the reload request should be considered cross-site,
cross-site, like the request that initially navigated to the page. like the request that initially navigated to the page.
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.4.7.1 allows a The "Lax" enforcement mode described in Section 5.4.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
requests with "unsafe" HTTP methods (as was the case prior to the with "unsafe" HTTP methods (as was the case prior to the introduction
introduction of the "SameSite" attribute). of the SameSite attribute).
For example, a login flow may involve a cross-site top-level "POST" For example, a login flow may involve a cross-site top-level POST
request to an endpoint which expects a cookie with login information. request to an endpoint which expects a cookie with login information.
For such a cookie, "Lax" enforcement is not appropriate, as it would For such a cookie, "Lax" enforcement is not appropriate, as it would
cause the cookie to be excluded due to the unsafe HTTP request cause the cookie to be excluded due to the unsafe HTTP request
method. On the other hand, "None" enforcement would allow the cookie method. On the other hand, "None" enforcement would allow the cookie
to be sent with all cross-site requests, which may not be desirable to be sent with all cross-site requests, which may not be desirable
due to the cookie's sensitive contents. due to the cookie's sensitive contents.
The "Lax-allowing-unsafe" enforcement mode described in The "Lax-allowing-unsafe" enforcement mode described in
Section 5.4.7.2 retains some of the protections of "Lax" enforcement Section 5.4.7.2 retains some of the protections of "Lax" enforcement
(as compared to "None") while still allowing cookies to be sent (as compared to "None") while still allowing cookies to be sent
skipping to change at page 49, line 7 skipping to change at page 50, line 7
attribute-names). attribute-names).
9.3.1. Procedure 9.3.1. Procedure
Each registered attribute name is associated with a description, and Each registered attribute name is associated with a description, and
a reference detailing how the attribute is to be processed and a reference detailing how the attribute is to be processed and
stored. stored.
New registrations happen on a "RFC Required" basis (see Section 4.7 New registrations happen on a "RFC Required" basis (see Section 4.7
of [RFC8126]). The attribute to be registered MUST match the of [RFC8126]). The attribute to be registered MUST match the
"extension-av" syntax defined in Section 4.1.1. Note that attribute extension-av syntax defined in Section 4.1.1. Note that attribute
names are generally defined in CamelCase, but technically accepted names are generally defined in CamelCase, but technically accepted
case-insensitively. case-insensitively.
9.3.2. Registration 9.3.2. Registration
The "Cookie Attribute Registry" should be created with the The "Cookie Attribute Registry" should be created with the
registrations below: registrations below:
+==========+==================================+ +==========+==================================+
| Name | Reference | | Name | Reference |
skipping to change at page 50, line 7 skipping to change at page 51, line 7
[FETCH] van Kesteren, A., "Fetch", n.d., [FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt, [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt,
P., and D. Denicola, "HTML", n.d., P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[HTTPSEM] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP [HTTPSEM] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-16, 27 May 2021, httpbis-semantics-19, 12 September 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
16>. semantics-19>.
[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/rfc/rfc1034>. <https://www.rfc-editor.org/rfc/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/rfc/rfc1123>. <https://www.rfc-editor.org/rfc/rfc1123>.
skipping to change at page 51, line 49 skipping to change at page 52, line 49
DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7,
ACM CCS '08: Proceedings of the 15th ACM conference on ACM CCS '08: Proceedings of the 15th ACM conference on
Computer and communications security (pages 75-88), Computer and communications security (pages 75-88),
October 2008, October 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>. <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[I-D.ietf-httpbis-cookie-alone] [I-D.ietf-httpbis-cookie-alone]
West, M., "Deprecate modification of 'secure' cookies from West, M., "Deprecate modification of 'secure' cookies from
non-secure origins", Work in Progress, Internet-Draft, non-secure origins", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cookie-alone-01, 5 September 2016, draft-ietf-httpbis-cookie-alone-01, 5 September 2016,
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
alone-01>. cookie-alone-01>.
[I-D.ietf-httpbis-cookie-prefixes] [I-D.ietf-httpbis-cookie-prefixes]
West, M., "Cookie Prefixes", Work in Progress, Internet- West, M., "Cookie Prefixes", Work in Progress, Internet-
Draft, draft-ietf-httpbis-cookie-prefixes-00, 23 February Draft, draft-ietf-httpbis-cookie-prefixes-00, 23 February
2016, <https://tools.ietf.org/html/draft-ietf-httpbis- 2016, <https://datatracker.ietf.org/doc/html/draft-ietf-
cookie-prefixes-00>. httpbis-cookie-prefixes-00>.
[I-D.ietf-httpbis-cookie-same-site] [I-D.ietf-httpbis-cookie-same-site]
West, M. and M. Goodwin, "Same-Site Cookies", Work in West, M. and M. Goodwin, "Same-Site Cookies", Work in
Progress, Internet-Draft, draft-ietf-httpbis-cookie-same- Progress, Internet-Draft, draft-ietf-httpbis-cookie-same-
site-00, 20 June 2016, <https://tools.ietf.org/html/draft- site-00, 20 June 2016,
ietf-httpbis-cookie-same-site-00>. <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cookie-same-site-00>.
[prerendering] [prerendering]
Bentzel, C., "Chrome Prerendering", n.d., Bentzel, C., "Chrome Prerendering", n.d.,
<https://www.chromium.org/developers/design-documents/ <https://www.chromium.org/developers/design-documents/
prerender>. prerender>.
[PSL] "Public Suffix List", n.d., [PSL] "Public Suffix List", n.d.,
<https://publicsuffix.org/list/>. <https://publicsuffix.org/list/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
skipping to change at page 53, line 34 skipping to change at page 54, line 34
* Fixes to formatting caused by mistakes in the initial port to * Fixes to formatting caused by mistakes in the initial port to
Markdown: Markdown:
- https://github.com/httpwg/http-extensions/issues/243 - https://github.com/httpwg/http-extensions/issues/243
(https://github.com/httpwg/http-extensions/issues/243) (https://github.com/httpwg/http-extensions/issues/243)
- https://github.com/httpwg/http-extensions/issues/246 - https://github.com/httpwg/http-extensions/issues/246
(https://github.com/httpwg/http-extensions/issues/246) (https://github.com/httpwg/http-extensions/issues/246)
* Addresses errata 3444 by updating the "path-value" and "extension- * Addresses errata 3444 by updating the path-value and extension-av
av" grammar, errata 4148 by updating the "day-of-month", "year", grammar, errata 4148 by updating the day-of-month, year, and time
and "time" grammar, and errata 3663 by adding the requested note. grammar, and errata 3663 by adding the requested note.
https://www.rfc-editor.org/errata_search.php?rfc=6265 https://www.rfc-editor.org/errata_search.php?rfc=6265
(https://www.rfc-editor.org/errata_search.php?rfc=6265) (https://www.rfc-editor.org/errata_search.php?rfc=6265)
* Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations * Dropped Cookie2 and Set-Cookie2 from the IANA Considerations
section: https://github.com/httpwg/http-extensions/issues/247 section: https://github.com/httpwg/http-extensions/issues/247
(https://github.com/httpwg/http-extensions/issues/247) (https://github.com/httpwg/http-extensions/issues/247)
* Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], * Merged the recommendations from [I-D.ietf-httpbis-cookie-alone],
removing the ability for a non-secure origin to set cookies with a removing the ability for a non-secure origin to set cookies with a
'secure' flag, and to overwrite cookies whose 'secure' flag is 'secure' flag, and to overwrite cookies whose 'secure' flag is
true. true.
* Merged the recommendations from * Merged the recommendations from
[I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and [I-D.ietf-httpbis-cookie-prefixes], adding __Secure- and __Host-
"__Host-" cookie name prefix processing instructions. cookie name prefix processing instructions.
A.3. draft-ietf-httpbis-rfc6265bis-02 A.3. draft-ietf-httpbis-rfc6265bis-02
* Merged the recommendations from * Merged the recommendations from
[I-D.ietf-httpbis-cookie-same-site], adding support for the [I-D.ietf-httpbis-cookie-same-site], adding support for the
"SameSite" attribute. SameSite attribute.
* Closed a number of editorial bugs: * Closed a number of editorial bugs:
- Clarified address bar behavior for SameSite cookies: - Clarified address bar behavior for SameSite cookies:
https://github.com/httpwg/http-extensions/issues/201 https://github.com/httpwg/http-extensions/issues/201
(https://github.com/httpwg/http-extensions/issues/201) (https://github.com/httpwg/http-extensions/issues/201)
- Added the word "Cookies" to the document's name: - Added the word "Cookies" to the document's name:
https://github.com/httpwg/http-extensions/issues/204 https://github.com/httpwg/http-extensions/issues/204
(https://github.com/httpwg/http-extensions/issues/204) (https://github.com/httpwg/http-extensions/issues/204)
- Clarified that the "__Host-" prefix requires an explicit "Path" - Clarified that the __Host- prefix requires an explicit Path
attribute: https://github.com/httpwg/http-extensions/issues/222 attribute: https://github.com/httpwg/http-extensions/issues/222
(https://github.com/httpwg/http-extensions/issues/222) (https://github.com/httpwg/http-extensions/issues/222)
- Expanded the options for dealing with third-party cookies to - Expanded the options for dealing with third-party cookies to
include a brief mention of partitioning based on first-party: include a brief mention of partitioning based on first-party:
https://github.com/httpwg/http-extensions/issues/248 https://github.com/httpwg/http-extensions/issues/248
(https://github.com/httpwg/http-extensions/issues/248) (https://github.com/httpwg/http-extensions/issues/248)
- Noted that double-quotes in cookie values are part of the - Noted that double-quotes in cookie values are part of the
value, and are not stripped: https://github.com/httpwg/http- value, and are not stripped: https://github.com/httpwg/http-
skipping to change at page 54, line 47 skipping to change at page 55, line 47
issues/302 (https://github.com/httpwg/http-extensions/ issues/302 (https://github.com/httpwg/http-extensions/
issues/302) issues/302)
A.4. draft-ietf-httpbis-rfc6265bis-03 A.4. draft-ietf-httpbis-rfc6265bis-03
* Clarified handling of invalid SameSite values: * Clarified handling of invalid SameSite values:
https://github.com/httpwg/http-extensions/issues/389 https://github.com/httpwg/http-extensions/issues/389
(https://github.com/httpwg/http-extensions/issues/389) (https://github.com/httpwg/http-extensions/issues/389)
* Reflect widespread implementation practice of including a cookie's * Reflect widespread implementation practice of including a cookie's
"host-only-flag" when calculating its uniqueness: host-only-flag when calculating its uniqueness:
https://github.com/httpwg/http-extensions/issues/199 https://github.com/httpwg/http-extensions/issues/199
(https://github.com/httpwg/http-extensions/issues/199) (https://github.com/httpwg/http-extensions/issues/199)
* Introduced an explicit "None" value for the SameSite attribute: * Introduced an explicit "None" value for the SameSite attribute:
https://github.com/httpwg/http-extensions/issues/788 https://github.com/httpwg/http-extensions/issues/788
(https://github.com/httpwg/http-extensions/issues/788) (https://github.com/httpwg/http-extensions/issues/788)
A.5. draft-ietf-httpbis-rfc6265bis-04 A.5. draft-ietf-httpbis-rfc6265bis-04
* Allow "SameSite" cookies to be set for all top-level navigations. * Allow SameSite cookies to be set for all top-level navigations.
https://github.com/httpwg/http-extensions/issues/594 https://github.com/httpwg/http-extensions/issues/594
(https://github.com/httpwg/http-extensions/issues/594) (https://github.com/httpwg/http-extensions/issues/594)
* Treat "Set-Cookie: token" as creating the cookie "("", "token")": * Treat Set-Cookie: token as creating the cookie ("", "token"):
https://github.com/httpwg/http-extensions/issues/159 https://github.com/httpwg/http-extensions/issues/159
(https://github.com/httpwg/http-extensions/issues/159) (https://github.com/httpwg/http-extensions/issues/159)
* Reject cookies with neither name nor value (e.g. "Set-Cookie: =" * Reject cookies with neither name nor value (e.g. Set-Cookie: =
and "Set-Cookie:": https://github.com/httpwg/http-extensions/ and Set-Cookie:: https://github.com/httpwg/http-extensions/
issues/159 (https://github.com/httpwg/http-extensions/issues/159) issues/159 (https://github.com/httpwg/http-extensions/issues/159)
* Clarified behavior of multiple "SameSite" attributes in a cookie * Clarified behavior of multiple SameSite attributes in a cookie
string: https://github.com/httpwg/http-extensions/issues/901 string: https://github.com/httpwg/http-extensions/issues/901
(https://github.com/httpwg/http-extensions/issues/901) (https://github.com/httpwg/http-extensions/issues/901)
A.6. draft-ietf-httpbis-rfc6265bis-05 A.6. draft-ietf-httpbis-rfc6265bis-05
* Typos and editorial fixes: https://github.com/httpwg/http- * Typos and editorial fixes: https://github.com/httpwg/http-
extensions/pull/1035 (https://github.com/httpwg/http-extensions/ extensions/pull/1035 (https://github.com/httpwg/http-extensions/
pull/1035), https://github.com/httpwg/http-extensions/pull/1038 pull/1035), https://github.com/httpwg/http-extensions/pull/1038
(https://github.com/httpwg/http-extensions/pull/1038), (https://github.com/httpwg/http-extensions/pull/1038),
https://github.com/httpwg/http-extensions/pull/1040 https://github.com/httpwg/http-extensions/pull/1040
skipping to change at page 56, line 5 skipping to change at page 57, line 5
* Editorial fixes: https://github.com/httpwg/http-extensions/ * Editorial fixes: https://github.com/httpwg/http-extensions/
issues/1059 (https://github.com/httpwg/http-extensions/ issues/1059 (https://github.com/httpwg/http-extensions/
issues/1059), https://github.com/httpwg/http-extensions/ issues/1059), https://github.com/httpwg/http-extensions/
issues/1158 (https://github.com/httpwg/http-extensions/ issues/1158 (https://github.com/httpwg/http-extensions/
issues/1158). issues/1158).
* Created a registry for cookie attribute names: * Created a registry for cookie attribute names:
https://github.com/httpwg/http-extensions/pull/1060 https://github.com/httpwg/http-extensions/pull/1060
(https://github.com/httpwg/http-extensions/pull/1060). (https://github.com/httpwg/http-extensions/pull/1060).
* Tweaks to ABNF for "cookie-pair" and the "Cookie" header * Tweaks to ABNF for cookie-pair and the Cookie header production:
production: https://github.com/httpwg/http-extensions/issues/1074 https://github.com/httpwg/http-extensions/issues/1074
(https://github.com/httpwg/http-extensions/issues/1074), (https://github.com/httpwg/http-extensions/issues/1074),
https://github.com/httpwg/http-extensions/issues/1119 https://github.com/httpwg/http-extensions/issues/1119
(https://github.com/httpwg/http-extensions/issues/1119). (https://github.com/httpwg/http-extensions/issues/1119).
* Fixed serialization for nameless/valueless cookies: * Fixed serialization for nameless/valueless cookies:
https://github.com/httpwg/http-extensions/pull/1143 https://github.com/httpwg/http-extensions/pull/1143
(https://github.com/httpwg/http-extensions/pull/1143). (https://github.com/httpwg/http-extensions/pull/1143).
* Converted a normative reference to Mozilla's Public Suffix List * Converted a normative reference to Mozilla's Public Suffix List
[PSL] into an informative reference: https://github.com/httpwg/ [PSL] into an informative reference: https://github.com/httpwg/
skipping to change at page 56, line 28 skipping to change at page 57, line 28
extensions/issues/1159). extensions/issues/1159).
A.8. draft-ietf-httpbis-rfc6265bis-07 A.8. draft-ietf-httpbis-rfc6265bis-07
* Moved instruction to ignore cookies with empty cookie-name and * Moved instruction to ignore cookies with empty cookie-name and
cookie-value from Section 5.4 to Section 5.5 to ensure that they cookie-value from Section 5.4 to Section 5.5 to ensure that they
apply to cookies created without parsing a cookie string: apply to cookies created without parsing a cookie string:
https://github.com/httpwg/http-extensions/issues/1234 https://github.com/httpwg/http-extensions/issues/1234
(https://github.com/httpwg/http-extensions/issues/1234). (https://github.com/httpwg/http-extensions/issues/1234).
* Add a default enforcement value to the "same-site-flag", * Add a default enforcement value to the same-site-flag, equivalent
equivalent to "SameSite=Lax": https://github.com/httpwg/http- to "SameSite=Lax": https://github.com/httpwg/http-extensions/
extensions/pull/1325 (https://github.com/httpwg/http-extensions/ pull/1325 (https://github.com/httpwg/http-extensions/pull/1325).
pull/1325).
* Require a Secure attribute for "SameSite=None": * Require a Secure attribute for "SameSite=None":
https://github.com/httpwg/http-extensions/pull/1323 https://github.com/httpwg/http-extensions/pull/1323
(https://github.com/httpwg/http-extensions/pull/1323). (https://github.com/httpwg/http-extensions/pull/1323).
* Consider scheme when running the same-site algorithm: * Consider scheme when running the same-site algorithm:
https://github.com/httpwg/http-extensions/pull/1324 https://github.com/httpwg/http-extensions/pull/1324
(https://github.com/httpwg/http-extensions/pull/1324). (https://github.com/httpwg/http-extensions/pull/1324).
A.9. draft-ietf-httpbis-rfc6265bis-08 A.9. draft-ietf-httpbis-rfc6265bis-08
skipping to change at page 57, line 26 skipping to change at page 58, line 26
(https://github.com/httpwg/http-extensions/pull/1428) (https://github.com/httpwg/http-extensions/pull/1428)
* Define "Lax-allowing-unsafe" SameSite enforcement mode: * Define "Lax-allowing-unsafe" SameSite enforcement mode:
https://github.com/httpwg/http-extensions/pull/1435 https://github.com/httpwg/http-extensions/pull/1435
(https://github.com/httpwg/http-extensions/pull/1435) (https://github.com/httpwg/http-extensions/pull/1435)
* Consistently use "header field" (vs 'header"): * Consistently use "header field" (vs 'header"):
https://github.com/httpwg/http-extensions/pull/1527 https://github.com/httpwg/http-extensions/pull/1527
(https://github.com/httpwg/http-extensions/pull/1527) (https://github.com/httpwg/http-extensions/pull/1527)
A.10. draft-ietf-httpbis-rfc6265bis-09
* Update cookie size requirements: https://github.com/httpwg/http-
extensions/pull/1563 (https://github.com/httpwg/http-extensions/
pull/1563)
* Reject cookies with control characters: https://github.com/httpwg/
http-extensions/pull/1576 (https://github.com/httpwg/http-
extensions/pull/1576)
* No longer treat horizontal tab as a control character:
https://github.com/httpwg/http-extensions/pull/1589
(https://github.com/httpwg/http-extensions/pull/1589)
* Specify empty domain attribute handling:
https://github.com/httpwg/http-extensions/pull/1709
(https://github.com/httpwg/http-extensions/pull/1709)
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.
Authors' Addresses Authors' Addresses
Lily Chen (editor) Lily Chen (editor)
Google LLC Google LLC
Email: chlily@google.com Email: chlily@google.com
Steven Englehardt (editor) Steven Englehardt (editor)
Mozilla Mozilla
Email: senglehardt@mozilla.com Email: senglehardt@mozilla.com
 End of changes. 125 change blocks. 
250 lines changed or deleted 274 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/