--- 1/draft-ietf-httpbis-rfc6265bis-08.txt 2021-10-19 08:13:06.614424387 -0700 +++ 2/draft-ietf-httpbis-rfc6265bis-09.txt 2021-10-19 08:13:06.674425111 -0700 @@ -1,23 +1,23 @@ HTTP L. Chen, Ed. Internet-Draft Google LLC Obsoletes: 6265 (if approved) S. Englehardt, Ed. Intended status: Standards Track Mozilla -Expires: 4 December 2021 M. West, Ed. +Expires: 22 April 2022 M. West, Ed. Google LLC J. Wilander, Ed. Apple, Inc - 2 June 2021 + 19 October 2021 Cookies: HTTP State Management Mechanism - draft-ietf-httpbis-rfc6265bis-08 + draft-ietf-httpbis-rfc6265bis-09 Abstract This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. @@ -43,21 +43,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -85,91 +85,92 @@ 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 - 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 5.2.1. Document-based requests . . . . . . . . . . . . . . . 21 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 23 5.4. The Set-Cookie Header Field . . . . . . . . . . . . . . . 23 5.4.1. The Expires Attribute . . . . . . . . . . . . . . . . 26 5.4.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26 5.4.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 5.4.4. The Path Attribute . . . . . . . . . . . . . . . . . 27 5.4.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 5.4.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 - 5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 28 - 5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 30 + 5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 + 5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 29 5.6. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 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 6. Implementation Considerations . . . . . . . . . . . . . . . . 38 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 6.2. Application Programming Interfaces . . . . . . . . . . . 38 - 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 38 + 6.2. Application Programming Interfaces . . . . . . . . . . . 39 + 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 39 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 - 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 39 + 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 40 7.2. Cookie policy . . . . . . . . . . . . . . . . . . . . . . 40 - 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 40 - 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 40 + 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 41 + 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41 - 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 41 + 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 42 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 42 - 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 42 - 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 43 + 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 43 + 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 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.1. Defense in depth . . . . . . . . . . . . . . . . . . 45 - 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 45 - 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 46 - 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 46 - 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 46 - 8.8.6. Top-level requests with "unsafe" methods . . . . . . 47 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 - 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 48 - 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 48 - 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 48 - 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 49 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 49 - 10.2. Informative References . . . . . . . . . . . . . . . . . 51 - Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 53 - A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 53 - A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 53 - A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 54 - A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 54 - A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 55 - A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 55 - A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 55 - A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 56 - A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 56 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 + 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 46 + 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 46 + 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 47 + 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 47 + 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 47 + 8.8.6. Top-level requests with "unsafe" methods . . . . . . 48 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 + 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 49 + 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 49 + 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 49 + 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 49 + 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 50 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 + 10.2. Informative References . . . . . . . . . . . . . . . . . 52 + Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 54 + A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 54 + A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 54 + A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 55 + A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 55 + A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 56 + A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 56 + A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 56 + A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 57 + A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 57 + A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 58 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header field. @@ -276,29 +277,29 @@ "top-level browsing context", and "WorkerGlobalScope" are defined in [HTML]. "Service Workers" are defined in the Service Workers specification [SERVICE-WORKERS]. The term "origin", the mechanism of deriving an origin from a URI, and the "the same" matching algorithm for origins are defined in [RFC6454]. - "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as - defined in Section 9.2.1 of [HTTPSEM]. + "Safe" HTTP methods include GET, HEAD, OPTIONS, and TRACE, as defined + in Section 9.2.1 of [HTTPSEM]. A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us". A domain's "registrable domain" is the domain's public suffix plus the label to its left. That is, for - "https://www.site.example", the public suffix is "example", and the - registrable domain is "site.example". Whenever possible, user agents + https://www.site.example, the public suffix is example, and the + registrable domain is site.example. Whenever possible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at [PSL]. The term "request", as well as a request's "client", "current url", "method", "target browsing context", and "url list", are defined in [FETCH]. 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 to scripts. @@ -323,21 +324,21 @@ Cookie header field does not preclude HTTP caches from storing and reusing a response. Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in Section 5.3 of [HTTPSEM]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such 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). 3.1. Examples 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 future HTTP requests that are within the scope of the cookie. For example, the server can send the user agent a "session identifier" named SID with the value 31d4d96e407aad42. The user agent then returns the session identifier in subsequent requests. @@ -600,42 +601,36 @@ 4.1.2.5. The Secure Attribute The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [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 The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via non-HTTP APIs. Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute. 4.1.2.7. The SameSite Attribute 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 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 origin with a scheme and registered domain of "https" and "site.example" respectively. 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 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 is "None", the cookie will be sent with same-site and cross-site requests. If the "SameSite" attribute's value is something other @@ -657,50 +652,50 @@ confidence in a backwards-compatible way, two common sets of requirements can be inferred from the first few characters of the cookie's name. The normative requirements for the prefixes described below are detailed in the storage model algorithm defined in Section 5.5. 4.1.3.1. The "__Secure-" Prefix 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. - For example, the following "Set-Cookie" header field would be - rejected by a conformant user agent, as it does not have a "Secure" - attribute. + For example, the following Set-Cookie header field would be rejected + by a conformant user agent, as it does not have a Secure attribute. 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 4.1.3.2. The "__Host-" Prefix 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" - attribute, a "Path" attribute with a value of "/", and no "Domain" - attribute. + __Host-, then the cookie will have been set with a Secure attribute, + a Path attribute with a value of /, and no Domain attribute. 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 - "Domain" attribute ensures that the cookie's "host-only-flag" is - true, locking the cookie to a particular host, rather than allowing - it to span subdomains. Setting the "Path" to "/" means that the - cookie is effective for the entire host, and won't be overridden for - specific paths. The "Secure" attribute ensures that the cookie is - unaltered by non-secure origins, and won't span protocols. + to treating the origin as a security boundary. The lack of a Domain + attribute ensures that the cookie's host-only-flag is true, locking + the cookie to a particular host, rather than allowing it to span + subdomains. Setting the Path to / means that the cookie is effective + for the entire host, and won't be overridden for specific paths. The + Secure attribute ensures that the cookie is unaltered by non-secure + 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. For example, the following cookies would always be rejected: Set-Cookie: __Host-SID=12345 Set-Cookie: __Host-SID=12345; Secure Set-Cookie: __Host-SID=12345; Domain=site.example Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/ Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/ @@ -959,106 +953,106 @@ For documents which are displayed in nested browsing contexts, we need to audit the origins of each of a document's ancestor browsing contexts' active documents in order to account for the "multiple- 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- level origin is same-site with the document's origin, and with each of the document's ancestor documents' origins. Otherwise its "site 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": - 1. Let "top-document" be the active document in "document"'s - browsing context's top-level browsing context. + 1. Let top-document be the active document in document's browsing + context's top-level browsing context. - 2. Let "top-origin" be the origin of "top-document"'s URI if "top- - document"'s sandboxed origin browsing context flag is set, and - "top-document"'s origin otherwise. + 2. Let top-origin be the origin of top-document's URI if top- + document's sandboxed origin browsing context flag is set, and + top-document's origin otherwise. - 3. Let "documents" be a list containing "document" and each of - "document"'s ancestor browsing contexts' active documents. + 3. Let documents be a list containing document and each of + 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 - sandboxed origin browsing context flag is set, and "item"'s - origin otherwise. + 1. Let origin be the origin of item's URI if item's sandboxed + origin browsing context flag is set, and item's origin + otherwise. - 2. If "origin" is not same-site with "top-origin", return an - origin set to an opaque origin. + 2. If origin is not same-site with top-origin, return an origin + set to an opaque origin. - 5. Return "top-origin". + 5. Return top-origin. 5.2.2. Worker-based requests Worker-driven requests aren't as clear-cut as document-driven requests, as there isn't a clear link between a top-level browsing context and a worker. This is especially true for Service Workers [SERVICE-WORKERS], which may execute code in the background, without any document visible at all. Note: The descriptions below assume that workers must be same-origin with the documents that instantiate them. If this invariant changes, we'll need to take the worker's script's URI into account when determining their status. 5.2.2.1. Dedicated and Shared Workers Dedicated workers are simple, as each dedicated worker is bound to one and only one document. Requests generated from a dedicated - worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define - their "site for cookies" as that document's "site for cookies". + worker (via importScripts, XMLHttpRequest, fetch(), etc) define their + "site for cookies" as that document's "site for cookies". Shared workers may be bound to multiple documents at once. As it is quite possible for those documents to have distinct "site for 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- site with the worker's origin, and the worker's origin in cases where the values agree. - Given a WorkerGlobalScope ("worker"), the following algorithm returns + Given a WorkerGlobalScope (worker), the following algorithm returns 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). - 2. If "document-site" is not same-site with "site", return an - origin set to an opaque origin. + 2. If document-site is not same-site with site, return an origin + set to an opaque origin. - 3. Return "site". + 3. Return site. 5.2.2.2. Service Workers Service Workers are more complicated, as they act as a completely separate execution context with only tangential relationship to the Document which registered them. Requests which simply pass through a Service Worker will be handled as described above: the request's client will be the Document or 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 Requests which are initiated by the Service Worker itself (via a - direct call to "fetch()", for instance), on the other hand, will have - a client which is a ServiceWorkerGlobalScope. Its "site for cookies" + direct call to fetch(), for instance), on the other hand, will have a + client which is a ServiceWorkerGlobalScope. Its "site for cookies" 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": - 1. Return "worker"'s origin. + 1. Return worker's origin. 5.3. Ignoring Set-Cookie Header Fields User agents MAY ignore Set-Cookie header fields contained in responses with 100-level status codes or based on its cookie policy (see Section 7.2). All other Set-Cookie header fields SHOULD be processed according to Section 5.4. That is, Set-Cookie header fields contained in responses with non-100-level status codes (including those in @@ -1079,59 +1073,60 @@ Section 4.1. For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in Section 4.1 forbids whitespace in these positions. In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in Section 4.1. User agents use this algorithm so as to interoperate 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 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 algorithm to parse a set-cookie-string: - 1. If the set-cookie-string contains a %x0D (CR), %x0A (LF), or %x00 - (NUL) octet, then set the set-cookie-string equal to all the - characters of set-cookie-string up to, but not including, the - 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. + 1. If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F + character (CTL characters excluding HTAB): 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, but not including, the first %x3B (";"), and the unparsed- attributes consist of the remainder of the set-cookie-string (including the %x3B (";") in question). Otherwise: 1. The name-value-pair string consists of all the characters contained in the set-cookie-string, and the unparsed- 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 name-value-pair. Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %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. + 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 value string. The user agent MUST use an algorithm equivalent to the following algorithm to parse the unparsed-attributes: 1. If the unparsed-attributes string is empty, skip the rest of these steps. 2. Discard the first character of the unparsed-attributes (which @@ -1158,25 +1153,28 @@ character. Otherwise: 1. The attribute-name string consists of the entire cookie-av string, and the attribute-value string is empty. 5. Remove any leading or trailing WSP characters from the attribute- 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 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 agent is said to "receive a cookie" from the request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute- list. (See Section 5.5 for additional requirements triggered by receiving a cookie.) 5.4.1. The Expires Attribute If the attribute-name case-insensitively matches the string @@ -1218,32 +1216,24 @@ seconds. 5. Append an attribute to the cookie-attribute-list with an attribute-name of Max-Age and an attribute-value of expiry-time. 5.4.3. The Domain Attribute If the attribute-name case-insensitively matches the string "Domain", the user agent MUST process the cookie-av as follows. - 1. If the attribute-value is empty, the behavior is undefined. - 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 attribute-value. - 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. 4. Append an attribute to the cookie-attribute-list with an attribute-name of Domain and an attribute-value of cookie-domain. 5.4.4. The Path Attribute If the attribute-name case-insensitively matches the string "Path", the user agent MUST process the cookie-av as follows. @@ -1271,85 +1261,85 @@ If the attribute-name case-insensitively matches the string "HttpOnly", the user agent MUST append an attribute to the cookie- attribute-list with an attribute-name of HttpOnly and an empty attribute-value. 5.4.7. The SameSite Attribute If the attribute-name case-insensitively matches the string "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 - "None", set "enforcement" to "None". + "None", set enforcement to "None". 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 - "Lax", set "enforcement" to "Lax". + "Lax", set enforcement to "Lax". 5. Append an attribute to the cookie-attribute-list with an attribute-name of "SameSite" and an attribute-value of - "enforcement". + enforcement. 5.4.7.1. "Strict" and "Lax" enforcement Same-site cookies in "Strict" enforcement mode will not be sent along with top-level navigations which are triggered from a cross-site document context. As discussed in Section 8.8.2, this might or might not be compatible with existing session management systems. In the 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 cookies along with cross-site requests if and only if they are top- level navigations which use a "safe" (in the [HTTPSEM] sense) HTTP 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]); in these cases, a request's "safe"ness is determined based on the method of the current redirect hop.) 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: 1. Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in Section 5.2.1), which is only a speedbump along the road to exploitation. - 2. Features like "" [prerendering] can be + 2. Features like [prerendering] can be exploited to create "same-site" requests without the risk of user detection. When possible, developers should use a session management mechanism such as that described in Section 8.8.2 to mitigate the risk of CSRF more completely. 5.4.7.2. "Lax-Allowing-Unsafe" enforcement As discussed in Section 8.8.6, compatibility concerns may necessitate 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 is a top-level request, regardless of request method. That is, 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, - 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 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" 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 mode, user agents which apply "Lax-allowing-unsafe" enforcement SHOULD restrict the enforcement to cookies which were created recently. Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit. If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST apply the following modification to the retrieval algorithm defined in Section 5.6.3: @@ -1378,29 +1368,33 @@ When the user agent "receives a cookie" from a request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute- list, the user agent MUST process the cookie as follows: 1. A user agent MAY ignore a received cookie in its entirety. See Section 5.3. 2. If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely. - 3. If the cookie-name or the cookie-value contains a %x00-1F / %x7F - (CTL) character, abort these steps and ignore the cookie + 3. If the cookie-name or the cookie-value contains a %x00-08 / + %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. - 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 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": 1. Set the cookie's persistent-flag to true. 2. Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute- name of "Max-Age". Otherwise, if the cookie-attribute-list contains an attribute with an attribute-name of "Expires" (and does not contain an @@ -1412,90 +1406,95 @@ attribute in the cookie-attribute-list with an attribute- name of "Expires". Otherwise: 1. Set the cookie's persistent-flag to false. 2. Set the cookie's expiry-time to the latest representable 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": 1. Let the domain-attribute be the attribute-value of the last - attribute in the cookie-attribute-list with an attribute- - name of "Domain". + attribute in the cookie-attribute-list with both an + 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: 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: 1. If the domain-attribute is identical to the canonicalized request-host: 1. Let the domain-attribute be the empty string. Otherwise: 1. Ignore the cookie entirely and abort these steps. - NOTE: This step prevents "attacker.example" from disrupting the - integrity of "site.example" by setting a cookie with a Domain + NOTE: This step prevents attacker.example from disrupting the + integrity of site.example by setting a cookie with a Domain 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 domain-attribute: 1. Ignore the cookie entirely and abort these steps. Otherwise: 1. Set the cookie's host-only-flag to false. 2. Set the cookie's domain to the domain-attribute. Otherwise: 1. Set the cookie's host-only-flag to true. 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- - value of the last attribute in the cookie-attribute-list with an - attribute-name of "Path". Otherwise, set the cookie's path to - the default-path of the request-uri. + value of the last attribute in the cookie-attribute-list with + both an attribute-name of "Path" and an attribute-value whose + 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 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 cookie's secure-only-flag is true, then abort these steps and 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 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 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, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: 1. Their name matches the name of the newly-created cookie. 2. Their secure-only-flag is true. 3. Their domain domain-matches the domain of the newly-created @@ -1505,91 +1504,91 @@ of the existing cookie. Note: The path comparison is not symmetric, ensuring only that a newly-created, non-secure cookie does not overlay an existing secure cookie, providing some mitigation against cookie-fixing attacks. That is, given an existing secure cookie named 'a' 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' 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 "Strict", "Lax", or "None", set the cookie's same-site-flag to the attribute-value of the last attribute in the cookie- attribute-list with an attribute-name of "SameSite". Otherwise, 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 API was called from a browsing context's active document whose "site for cookies" is not same-site with the top-level origin, then abort these steps and ignore the newly created cookie entirely. 2. If the cookie was received from a "same-site" request (as defined in Section 5.2), skip the remaining substeps and continue processing the cookie. 3. If the cookie was received from a request which is navigating a top-level browsing context [HTML] (e.g. if the - request's "reserved client" is either "null" or an - environment whose "target browsing context" is a top-level - browing context), skip the remaining substeps and continue + request's "reserved client" is either null or an environment + whose "target browsing context" is a top-level browing + context), skip the remaining substeps and continue processing the cookie. 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 the navigation. 4. Abort these steps and ignore the newly created cookie 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- 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 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 entirely unless the cookie meets all the following criteria: 1. The cookie's secure-only-flag is true. 2. The cookie's host-only-flag is true. 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: 1. Let old-cookie be the existing cookie with the same name, domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) 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 steps and ignore the newly created cookie entirely. 3. Update the creation-time of the newly-created cookie to match the creation-time of the old-cookie. 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. The user agent MUST evict all expired cookies from 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 cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies). @@ -1753,35 +1752,40 @@ octets is valid UTF-8. 6. Implementation Considerations 6.1. Limits Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD 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 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 reaching these implementation limits and to minimize network bandwidth due to the Cookie header field being included in every request. Servers SHOULD gracefully degrade if the user agent fails to return 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 One reason the Cookie and Set-Cookie header fields use such esoteric syntax is that many platforms (both in servers and user agents) provide a string-based application programming interface (API) to cookies, requiring application-layer programmers to generate and parse the syntax used by the Cookie and Set-Cookie header fields, which many programmers have done incorrectly, resulting in interoperability problems. @@ -1826,21 +1830,23 @@ another site that contains content from the same third party, the third party can track the user between the two sites. Given this risk to user privacy, some user agents restrict how third- party cookies behave, and those restrictions vary widly. For instance, user agents might block third-party cookies entirely by refusing to send Cookie header fields or process Set-Cookie header fields during third-party requests. They might take a less draconian approach by partitioning cookies based on the first-party context, 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 third-party cookie policies that balance the privacy and compatibility needs of their users. However, this document does not endorse any particular third-party cookie policy. Third-party cookie blocking policies are often ineffective at achieving their privacy goals if servers attempt to work around their restrictions to track users. In particular, two collaborating servers can often track users without using cookies at all by @@ -2063,24 +2069,25 @@ An active network attacker can also inject cookies into the Cookie header field sent to https://site.example/ by impersonating a response from http://site.example/ and injecting a Set-Cookie header field. The HTTPS server at site.example will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against site.example even if site.example uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and - signing the contents of their cookies. However, using cryptography - does not mitigate the issue completely because an attacker can replay - a cookie he or she received from the authentic site.example server in - the user's session, with unpredictable results. + signing the contents of their cookies, or by naming the cookie with + the __Secure- prefix. However, using cryptography does not mitigate + the issue completely because an attacker can replay a cookie he or + 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 cookies by storing a large number of cookies. Once the user agent reaches its storage limit, the user agent will be forced to evict some cookies. Servers SHOULD NOT rely upon user agents retaining cookies. 8.7. Reliance on DNS Cookies rely upon the Domain Name System (DNS) for security. If the @@ -2101,60 +2107,59 @@ Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully. Additionally, client-side techniques such as those described in [app-isolation] may also prove effective against CSRF, and are certainly worth exploring in combination with "SameSite" cookies. 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 confuse users unless sites' developers carefully ensure that their cookie-based session management systems deal reasonably well with top-level navigations. Consider the scenario in which a user reads their email at MegaCorp - Inc's webmail provider "https://site.example/". They might expect - that clicking on an emailed link to "https://projects.example/secret/ - project" would show them the secret project that they're authorized - to see, but if "https://projects.example" has marked their session - cookies as "SameSite=Strict", then this cross-site navigation won't - send them along with the request. "https://projects.example" will - render a 404 error to avoid leaking secret information, and the user - will be quite confused. + Inc's webmail provider https://site.example/. They might expect that + clicking on an emailed link to https://projects.example/secret/ + project would show them the secret project that they're authorized to + see, but if https://projects.example has marked their session cookies + as SameSite=Strict, then this cross-site navigation won't send them + along with the request. https://projects.example will render a 404 + error to avoid leaking secret information, and the user will be quite + confused. Developers can avoid this confusion by adopting a session management system that relies on not one, but two cookies: one conceptually 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. - The former could be marked as "SameSite=Lax", in order to allow users - access to data via top-level navigation, or "SameSite=None", to - permit access in all contexts (including cross-site embedded - contexts). + The former could be marked as SameSite=Lax, in order to allow users + access to data via top-level navigation, or SameSite=None, to permit + access in all contexts (including cross-site embedded contexts). 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 content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in - these situations should be marked with "SameSite=None" to allow - access in cross-site contexts. + these situations should be marked with SameSite=None to allow access + in cross-site contexts. Likewise, some forms of Single-Sign-On might require cookie-based authentication in a cross-site context; these mechanisms will not function as intended with same-site cookies and will also require - "SameSite=None". + SameSite=None. 8.8.4. Server-controlled SameSite cookies in and of themselves don't do anything to address the general privacy concerns outlined in Section 7.1 of [RFC6265]. The "SameSite" attribute is set by the server, and serves to mitigate the risk of certain kinds of attacks that the server is worried about. The user is not involved in this decision. Moreover, a number of side-channels exist which could allow a server to link distinct requests even in the absence of cookies (for example, @@ -2164,56 +2169,56 @@ 8.8.5. Reload navigations Requests issued for reloads triggered through user interface elements (such as a refresh button on a toolbar) are same-site only if the reloaded document was originally navigated to via a same-site request. This differs from the handling of other reload navigations, which are always same-site if top-level, since the source browsing context's active document is precisely the document being reloaded. This special handling of reloads triggered through a user interface - element avoids sending "SameSite" cookies on user-initiated reloads - if they were withheld on the original navigation (i.e., if the - initial navigation were cross-site). If the reload navigation were - instead considered same-site, and sent all the initially withheld - "SameSite" cookies, the security benefits of withholding the cookies - in the first place would be nullified. This is especially important - given that the absence of "SameSite" cookies withheld on a cross-site + element avoids sending SameSite cookies on user-initiated reloads if + they were withheld on the original navigation (i.e., if the initial + navigation were cross-site). If the reload navigation were instead + considered same-site, and sent all the initially withheld SameSite + cookies, the security benefits of withholding the cookies in the + first place would be nullified. This is especially important given + that the absence of SameSite cookies withheld on a cross-site navigation request may lead to visible site breakage, prompting the user to trigger a reload. For example, suppose the user clicks on a link from - "https://attacker.example/" to "https://victim.example/". This is a - cross-site request, so "SameSite=Strict" cookies are withheld. - Suppose this causes "https://victim.example/" to appear broken, - because the site only displays its sensitive content if a particular - "SameSite" cookie is present in the request. The user, frustrated by - the unexpectedly broken site, presses refresh on their browser's - toolbar. To now consider the reload request same-site and send the - initially withheld "SameSite" cookie would defeat the purpose of - withholding it in the first place, as the reload navigation triggered - through the user interface may replay the original (potentially - malicious) request. Thus, the reload request should be considered - cross-site, like the request that initially navigated to the page. + https://attacker.example/ to https://victim.example/. This is a + cross-site request, so SameSite=Strict cookies are withheld. Suppose + this causes https://victim.example/ to appear broken, because the + site only displays its sensitive content if a particular SameSite + cookie is present in the request. The user, frustrated by the + unexpectedly broken site, presses refresh on their browser's toolbar. + To now consider the reload request same-site and send the initially + withheld SameSite cookie would defeat the purpose of withholding it + in the first place, as the reload navigation triggered through the + user interface may replay the original (potentially malicious) + request. Thus, the reload request should be considered cross-site, + like the request that initially navigated to the page. 8.8.6. Top-level requests with "unsafe" methods 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 a top-level navigation with a "safe" HTTP method. Implementation experience shows that this is difficult to apply as the default behavior, as some sites may rely on cookies not explicitly specifying - a "SameSite" attribute being included on top-level cross-site - requests with "unsafe" HTTP methods (as was the case prior to the - introduction of the "SameSite" attribute). + a SameSite attribute being included on top-level cross-site requests + with "unsafe" HTTP methods (as was the case prior to the introduction + 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. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method. On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. The "Lax-allowing-unsafe" enforcement mode described in Section 5.4.7.2 retains some of the protections of "Lax" enforcement (as compared to "None") while still allowing cookies to be sent @@ -2265,21 +2270,21 @@ attribute-names). 9.3.1. Procedure Each registered attribute name is associated with a description, and a reference detailing how the attribute is to be processed and stored. New registrations happen on a "RFC Required" basis (see Section 4.7 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 case-insensitively. 9.3.2. Registration The "Cookie Attribute Registry" should be created with the registrations below: +==========+==================================+ | Name | Reference | @@ -2311,23 +2316,23 @@ [FETCH] van Kesteren, A., "Fetch", n.d., . [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt, P., and D. Denicola, "HTML", n.d., . [HTTPSEM] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- - httpbis-semantics-16, 27 May 2021, - . + httpbis-semantics-19, 12 September 2021, + . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . @@ -2398,34 +2403,35 @@ DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, ACM CCS '08: Proceedings of the 15th ACM conference on Computer and communications security (pages 75-88), October 2008, . [I-D.ietf-httpbis-cookie-alone] West, M., "Deprecate modification of 'secure' cookies from non-secure origins", Work in Progress, Internet-Draft, draft-ietf-httpbis-cookie-alone-01, 5 September 2016, - . + . [I-D.ietf-httpbis-cookie-prefixes] West, M., "Cookie Prefixes", Work in Progress, Internet- Draft, draft-ietf-httpbis-cookie-prefixes-00, 23 February - 2016, . + 2016, . [I-D.ietf-httpbis-cookie-same-site] West, M. and M. Goodwin, "Same-Site Cookies", Work in Progress, Internet-Draft, draft-ietf-httpbis-cookie-same- - site-00, 20 June 2016, . + site-00, 20 June 2016, + . [prerendering] Bentzel, C., "Chrome Prerendering", n.d., . [PSL] "Public Suffix List", n.d., . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, @@ -2477,56 +2483,56 @@ * Fixes to formatting caused by mistakes in the initial port to Markdown: - 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) - * Addresses errata 3444 by updating the "path-value" and "extension- - av" grammar, errata 4148 by updating the "day-of-month", "year", - and "time" grammar, and errata 3663 by adding the requested note. + * Addresses errata 3444 by updating the path-value and extension-av + grammar, errata 4148 by updating the day-of-month, year, and time + 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) - * 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 (https://github.com/httpwg/http-extensions/issues/247) * Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is true. * Merged the recommendations from - [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and - "__Host-" cookie name prefix processing instructions. + [I-D.ietf-httpbis-cookie-prefixes], adding __Secure- and __Host- + cookie name prefix processing instructions. A.3. draft-ietf-httpbis-rfc6265bis-02 * Merged the recommendations from [I-D.ietf-httpbis-cookie-same-site], adding support for the - "SameSite" attribute. + SameSite attribute. * Closed a number of editorial bugs: - Clarified address bar behavior for SameSite cookies: 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: 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 (https://github.com/httpwg/http-extensions/issues/222) - Expanded the options for dealing with third-party cookies to 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) - Noted that double-quotes in cookie values are part of the value, and are not stripped: https://github.com/httpwg/http- @@ -2538,43 +2544,43 @@ issues/302 (https://github.com/httpwg/http-extensions/ issues/302) A.4. draft-ietf-httpbis-rfc6265bis-03 * Clarified handling of invalid SameSite values: 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 - "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) * 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) 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) - * 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) - * Reject cookies with neither name nor value (e.g. "Set-Cookie: =" - and "Set-Cookie:": https://github.com/httpwg/http-extensions/ + * Reject cookies with neither name nor value (e.g. Set-Cookie: = + and Set-Cookie:: https://github.com/httpwg/http-extensions/ 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 (https://github.com/httpwg/http-extensions/issues/901) A.6. draft-ietf-httpbis-rfc6265bis-05 * Typos and editorial fixes: https://github.com/httpwg/http- extensions/pull/1035 (https://github.com/httpwg/http-extensions/ 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/1040 @@ -2587,22 +2593,22 @@ * 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/1158 (https://github.com/httpwg/http-extensions/ issues/1158). * Created a registry for cookie attribute names: 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 - production: https://github.com/httpwg/http-extensions/issues/1074 + * Tweaks to ABNF for cookie-pair and the Cookie header production: + 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). * Fixed serialization for nameless/valueless cookies: 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 [PSL] into an informative reference: https://github.com/httpwg/ @@ -2610,24 +2616,23 @@ extensions/issues/1159). A.8. draft-ietf-httpbis-rfc6265bis-07 * Moved instruction to ignore cookies with empty cookie-name and cookie-value from Section 5.4 to Section 5.5 to ensure that they 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). - * Add a default enforcement value to the "same-site-flag", - equivalent to "SameSite=Lax": https://github.com/httpwg/http- - extensions/pull/1325 (https://github.com/httpwg/http-extensions/ - pull/1325). + * Add a default enforcement value to the same-site-flag, equivalent + to "SameSite=Lax": https://github.com/httpwg/http-extensions/ + pull/1325 (https://github.com/httpwg/http-extensions/pull/1325). * Require a Secure attribute for "SameSite=None": https://github.com/httpwg/http-extensions/pull/1323 (https://github.com/httpwg/http-extensions/pull/1323). * Consider scheme when running the same-site algorithm: https://github.com/httpwg/http-extensions/pull/1324 (https://github.com/httpwg/http-extensions/pull/1324). A.9. draft-ietf-httpbis-rfc6265bis-08 @@ -2655,29 +2660,46 @@ (https://github.com/httpwg/http-extensions/pull/1428) * Define "Lax-allowing-unsafe" SameSite enforcement mode: https://github.com/httpwg/http-extensions/pull/1435 (https://github.com/httpwg/http-extensions/pull/1435) * Consistently use "header field" (vs 'header"): 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 RFC 6265 was written by Adam Barth. This document is an update of RFC 6265, adding features and aligning the specification with 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. Authors' Addresses - Lily Chen (editor) Google LLC Email: chlily@google.com Steven Englehardt (editor) Mozilla Email: senglehardt@mozilla.com