idnits 2.17.1 draft-ietf-httpbis-rfc6265bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 2017) is 2452 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' -- Possible downref: Non-RFC (?) normative reference: ref. 'PSL' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'SERVICE-WORKERS' -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group A. Barth 3 Internet-Draft M. West 4 Obsoletes: 6265 (if approved) Google, Inc 5 Intended status: Standards Track August 7, 2017 6 Expires: February 8, 2018 8 Cookies: HTTP State Management Mechanism 9 draft-ietf-httpbis-rfc6265bis-02 11 Abstract 13 This document defines the HTTP Cookie and Set-Cookie header fields. 14 These header fields can be used by HTTP servers to store state 15 (called cookies) at HTTP user agents, letting the servers maintain a 16 stateful session over the mostly stateless HTTP protocol. Although 17 cookies have many historical infelicities that degrade their security 18 and privacy, the Cookie and Set-Cookie header fields are widely used 19 on the Internet. This document obsoletes RFC 6265. 21 Note to Readers 23 Discussion of this draft takes place on the HTTP working group 24 mailing list (ietf-http-wg@w3.org), which is archived at 25 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 27 Working Group information can be found at http://httpwg.github.io/ ; 28 source code and issues list for this draft can be found at 29 https://github.com/httpwg/http-extensions/labels/6265bis . 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 8, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 80 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 82 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 85 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 88 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 89 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 92 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 93 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16 94 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16 95 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18 96 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 97 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 98 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 99 5.2.1. Document-based requests . . . . . . . . . . . . . . . 20 100 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 21 101 5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23 102 5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25 103 5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 25 104 5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 105 5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 26 106 5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 107 5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 108 5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 109 5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28 110 5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33 111 6. Implementation Considerations . . . . . . . . . . . . . . . . 35 112 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35 113 6.2. Application Programming Interfaces . . . . . . . . . . . 35 114 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 35 115 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 116 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36 117 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37 118 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 120 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 37 121 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38 122 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 38 123 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 39 124 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40 125 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 40 126 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 41 127 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 41 128 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 41 129 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42 130 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 42 131 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 133 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43 134 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 136 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 137 10.2. Informative References . . . . . . . . . . . . . . . . . 45 138 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 47 139 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 47 140 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 47 141 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48 142 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 145 1. Introduction 147 This document defines the HTTP Cookie and Set-Cookie header fields. 148 Using the Set-Cookie header field, an HTTP server can pass name/value 149 pairs and associated metadata (called cookies) to a user agent. When 150 the user agent makes subsequent requests to the server, the user 151 agent uses the metadata and other information to determine whether to 152 return the name/value pairs in the Cookie header. 154 Although simple on their surface, cookies have a number of 155 complexities. For example, the server indicates a scope for each 156 cookie when sending it to the user agent. The scope indicates the 157 maximum amount of time in which the user agent should return the 158 cookie, the servers to which the user agent should return the cookie, 159 and the URI schemes for which the cookie is applicable. 161 For historical reasons, cookies contain a number of security and 162 privacy infelicities. For example, a server can indicate that a 163 given cookie is intended for "secure" connections, but the Secure 164 attribute does not provide integrity in the presence of an active 165 network attacker. Similarly, cookies for a given host are shared 166 across all the ports on that host, even though the usual "same-origin 167 policy" used by web browsers isolates content retrieved via different 168 ports. 170 There are two audiences for this specification: developers of cookie- 171 generating servers and developers of cookie-consuming user agents. 173 To maximize interoperability with user agents, servers SHOULD limit 174 themselves to the well-behaved profile defined in Section 4 when 175 generating cookies. 177 User agents MUST implement the more liberal processing rules defined 178 in Section 5, in order to maximize interoperability with existing 179 servers that do not conform to the well-behaved profile defined in 180 Section 4. 182 This document specifies the syntax and semantics of these headers as 183 they are actually used on the Internet. In particular, this document 184 does not create new syntax or semantics beyond those in use today. 185 The recommendations for cookie generation provided in Section 4 186 represent a preferred subset of current server behavior, and even the 187 more liberal cookie processing algorithm provided in Section 5 does 188 not recommend all of the syntactic and semantic variations in use 189 today. Where some existing software differs from the recommended 190 protocol in significant ways, the document contains a note explaining 191 the difference. 193 This document obsoletes [RFC6265]. 195 2. Conventions 197 2.1. Conformance Criteria 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in [RFC2119]. 203 Requirements phrased in the imperative as part of algorithms (such as 204 "strip any leading space characters" or "return false and abort these 205 steps") are to be interpreted with the meaning of the key word 206 ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. 208 Conformance requirements phrased as algorithms or specific steps can 209 be implemented in any manner, so long as the end result is 210 equivalent. In particular, the algorithms defined in this 211 specification are intended to be easy to understand and are not 212 intended to be performant. 214 2.2. Syntax Notation 216 This specification uses the Augmented Backus-Naur Form (ABNF) 217 notation of [RFC5234]. 219 The following core rules are included by reference, as defined in 220 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 221 (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 222 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), 223 OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB 224 (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible 225 [USASCII] character), and WSP (whitespace). 227 The OWS (optional whitespace) rule is used where zero or more linear 228 whitespace characters MAY appear: 230 OWS = *( [ obs-fold ] WSP ) 231 ; "optional" whitespace 232 obs-fold = CRLF 234 OWS SHOULD either not be produced or be produced as a single SP 235 character. 237 2.3. Terminology 239 The terms "user agent", "client", "server", "proxy", and "origin 240 server" have the same meaning as in the HTTP/1.1 specification 241 ([RFC2616], Section 1.3). 243 The request-host is the name of the host, as known by the user agent, 244 to which the user agent is sending an HTTP request or from which it 245 is receiving an HTTP response (i.e., the name of the host to which it 246 sent the corresponding HTTP request). 248 The term request-uri is defined in Section 5.1.2 of [RFC2616]. 250 Two sequences of octets are said to case-insensitively match each 251 other if and only if they are equivalent under the i;ascii-casemap 252 collation defined in [RFC4790]. 254 The term string means a sequence of non-NUL octets. 256 The terms "active document", "ancestor browsing context", "browsing 257 context", "dedicated worker", "Document", "WorkerGlobalScope", 258 "sandboxed origin browsing context flag", "parent browsing context", 259 "shared worker", "the worker's Documents", "nested browsing context", 260 and "top-level browsing context" are defined in [HTML]. 262 "Service Workers" are defined in the Service Workers specification 263 [SERVICE-WORKERS]. 265 The term "origin", the mechanism of deriving an origin from a URI, 266 and the "the same" matching algorithm for origins are defined in 267 [RFC6454]. 269 "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as 270 defined in Section 4.2.1 of [RFC7231]. 272 The term "public suffix" is defined in a note in Section 5.3 of 273 [RFC6265] as "a domain that is controlled by a public registry", and 274 are also know as "effective top-level domains" (eTLDs). For example, 275 "example.com"'s public suffix is "com". User agents SHOULD use an 276 up-to-date public suffix list, such as the one maintained by Mozilla 277 at [PSL]. 279 An origin's "registered domain" is the origin's host's public suffix 280 plus the label to its left. That is, for "https://www.example.com", 281 the public suffix is "com", and the registered domain is 282 "example.com". This concept is defined more rigorously in [PSL], and 283 is also know as "effective top-level domain plus one" (eTLD+1). 285 The term "request", as well as a request's "client", "current url", 286 "method", and "target browsing context", are defined in [FETCH]. 288 3. Overview 290 This section outlines a way for an origin server to send state 291 information to a user agent and for the user agent to return the 292 state information to the origin server. 294 To store state, the origin server includes a Set-Cookie header in an 295 HTTP response. In subsequent requests, the user agent returns a 296 Cookie request header to the origin server. The Cookie header 297 contains cookies the user agent received in previous Set-Cookie 298 headers. The origin server is free to ignore the Cookie header or 299 use its contents for an application-defined purpose. 301 Origin servers MAY send a Set-Cookie response header with any 302 response. User agents MAY ignore Set-Cookie headers contained in 303 responses with 100-level status codes but MUST process Set-Cookie 304 headers contained in other responses (including responses with 400- 305 and 500-level status codes). An origin server can include multiple 306 Set-Cookie header fields in a single response. The presence of a 307 Cookie or a Set-Cookie header field does not preclude HTTP caches 308 from storing and reusing a response. 310 Origin servers SHOULD NOT fold multiple Set-Cookie header fields into 311 a single header field. The usual mechanism for folding HTTP headers 312 fields (i.e., as defined in [RFC2616]) might change the semantics of 313 the Set-Cookie header field because the %x2C (",") character is used 314 by Set-Cookie in a way that conflicts with such folding. 316 3.1. Examples 318 Using the Set-Cookie header, a server can send the user agent a short 319 string in an HTTP response that the user agent will return in future 320 HTTP requests that are within the scope of the cookie. For example, 321 the server can send the user agent a "session identifier" named SID 322 with the value 31d4d96e407aad42. The user agent then returns the 323 session identifier in subsequent requests. 325 == Server -> User Agent == 327 Set-Cookie: SID=31d4d96e407aad42 329 == User Agent -> Server == 331 Cookie: SID=31d4d96e407aad42 332 The server can alter the default scope of the cookie using the Path 333 and Domain attributes. For example, the server can instruct the user 334 agent to return the cookie to every path and every subdomain of 335 example.com. 337 == Server -> User Agent == 339 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com 341 == User Agent -> Server == 343 Cookie: SID=31d4d96e407aad42 345 As shown in the next example, the server can store multiple cookies 346 at the user agent. For example, the server can store a session 347 identifier as well as the user's preferred language by returning two 348 Set-Cookie header fields. Notice that the server uses the Secure and 349 HttpOnly attributes to provide additional security protections for 350 the more sensitive session identifier (see Section 4.1.2). 352 == Server -> User Agent == 354 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 355 Set-Cookie: lang=en-US; Path=/; Domain=example.com 357 == User Agent -> Server == 359 Cookie: SID=31d4d96e407aad42; lang=en-US 361 Notice that the Cookie header above contains two cookies, one named 362 SID and one named lang. If the server wishes the user agent to 363 persist the cookie over multiple "sessions" (e.g., user agent 364 restarts), the server can specify an expiration date in the Expires 365 attribute. Note that the user agent might delete the cookie before 366 the expiration date if the user agent's cookie store exceeds its 367 quota or if the user manually deletes the server's cookie. 369 == Server -> User Agent == 371 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 373 == User Agent -> Server == 375 Cookie: SID=31d4d96e407aad42; lang=en-US 377 Finally, to remove a cookie, the server returns a Set-Cookie header 378 with an expiration date in the past. The server will be successful 379 in removing the cookie only if the Path and the Domain attribute in 380 the Set-Cookie header match the values used when the cookie was 381 created. 383 == Server -> User Agent == 385 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 387 == User Agent -> Server == 389 Cookie: SID=31d4d96e407aad42 391 4. Server Requirements 393 This section describes the syntax and semantics of a well-behaved 394 profile of the Cookie and Set-Cookie headers. 396 4.1. Set-Cookie 398 The Set-Cookie HTTP response header is used to send cookies from the 399 server to the user agent. 401 4.1.1. Syntax 403 Informally, the Set-Cookie response header contains the header name 404 "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with 405 a name-value-pair, followed by zero or more attribute-value pairs. 406 Servers SHOULD NOT send Set-Cookie headers that fail to conform to 407 the following grammar: 409 set-cookie-header = "Set-Cookie:" SP set-cookie-string 410 set-cookie-string = cookie-pair *( ";" SP cookie-av ) 411 cookie-pair = cookie-name "=" cookie-value 412 cookie-name = token 413 cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) 414 cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E 415 ; US-ASCII characters excluding CTLs, 416 ; whitespace DQUOTE, comma, semicolon, 417 ; and backslash 418 token = 420 cookie-av = expires-av / max-age-av / domain-av / 421 path-av / secure-av / httponly-av / 422 samesite-av / extension-av 423 expires-av = "Expires=" sane-cookie-date 424 sane-cookie-date = 425 426 max-age-av = "Max-Age=" non-zero-digit *DIGIT 427 ; In practice, both expires-av and max-age-av 428 ; are limited to dates representable by the 429 ; user agent. 430 non-zero-digit = %x31-39 431 ; digits 1 through 9 432 domain-av = "Domain=" domain-value 433 domain-value = 434 ; defined in [RFC1034], Section 3.5, as 435 ; enhanced by [RFC1123], Section 2.1 436 path-av = "Path=" path-value 437 path-value = *av-octet 438 secure-av = "Secure" 439 httponly-av = "HttpOnly" 440 samesite-av = "SameSite=" samesite-value 441 samesite-value = "Strict" / "Lax" 442 extension-av = *av-octet 443 av-octet = %x20-3A / %x3C-7E 444 ; any CHAR except CTLs or ";" 446 Note that some of the grammatical terms above reference documents 447 that use different grammatical notations than this document (which 448 uses ABNF from [RFC5234]). 450 The semantics of the cookie-value are not defined by this document. 452 To maximize compatibility with user agents, servers that wish to 453 store arbitrary data in a cookie-value SHOULD encode that data, for 454 example, using Base64 [RFC4648]. 456 Per the grammar above, the cookie-value MAY be wrapped in DQUOTE 457 characters. Note that in this case, the initial and trailing DQUOTE 458 characters are not stripped. They are part of the cookie-value, and 459 will be included in Cookie headers sent to the server. 461 The portions of the set-cookie-string produced by the cookie-av term 462 are known as attributes. To maximize compatibility with user agents, 463 servers SHOULD NOT produce two attributes with the same name in the 464 same set-cookie-string. (See Section 5.4 for how user agents handle 465 this case.) 467 Servers SHOULD NOT include more than one Set-Cookie header field in 468 the same response with the same cookie-name. (See Section 5.3 for 469 how user agents handle this case.) 471 If a server sends multiple responses containing Set-Cookie headers 472 concurrently to the user agent (e.g., when communicating with the 473 user agent over multiple sockets), these responses create a "race 474 condition" that can lead to unpredictable behavior. 476 NOTE: Some existing user agents differ in their interpretation of 477 two-digit years. To avoid compatibility issues, servers SHOULD use 478 the rfc1123-date format, which requires a four-digit year. 480 NOTE: Some user agents store and process dates in cookies as 32-bit 481 UNIX time_t values. Implementation bugs in the libraries supporting 482 time_t processing on some systems might cause such user agents to 483 process dates after the year 2038 incorrectly. 485 4.1.2. Semantics (Non-Normative) 487 This section describes simplified semantics of the Set-Cookie header. 488 These semantics are detailed enough to be useful for understanding 489 the most common uses of cookies by servers. The full semantics are 490 described in Section 5. 492 When the user agent receives a Set-Cookie header, the user agent 493 stores the cookie together with its attributes. Subsequently, when 494 the user agent makes an HTTP request, the user agent includes the 495 applicable, non-expired cookies in the Cookie header. 497 If the user agent receives a new cookie with the same cookie-name, 498 domain-value, and path-value as a cookie that it has already stored, 499 the existing cookie is evicted and replaced with the new cookie. 500 Notice that servers can delete cookies by sending the user agent a 501 new cookie with an Expires attribute with a value in the past. 503 Unless the cookie's attributes indicate otherwise, the cookie is 504 returned only to the origin server (and not, for example, to any 505 subdomains), and it expires at the end of the current session (as 506 defined by the user agent). User agents ignore unrecognized cookie 507 attributes (but not the entire cookie). 509 4.1.2.1. The Expires Attribute 511 The Expires attribute indicates the maximum lifetime of the cookie, 512 represented as the date and time at which the cookie expires. The 513 user agent is not required to retain the cookie until the specified 514 date has passed. In fact, user agents often evict cookies due to 515 memory pressure or privacy concerns. 517 4.1.2.2. The Max-Age Attribute 519 The Max-Age attribute indicates the maximum lifetime of the cookie, 520 represented as the number of seconds until the cookie expires. The 521 user agent is not required to retain the cookie for the specified 522 duration. In fact, user agents often evict cookies due to memory 523 pressure or privacy concerns. 525 NOTE: Some existing user agents do not support the Max-Age attribute. 526 User agents that do not support the Max-Age attribute ignore the 527 attribute. 529 If a cookie has both the Max-Age and the Expires attribute, the Max- 530 Age attribute has precedence and controls the expiration date of the 531 cookie. If a cookie has neither the Max-Age nor the Expires 532 attribute, the user agent will retain the cookie until "the current 533 session is over" (as defined by the user agent). 535 4.1.2.3. The Domain Attribute 537 The Domain attribute specifies those hosts to which the cookie will 538 be sent. For example, if the value of the Domain attribute is 539 "example.com", the user agent will include the cookie in the Cookie 540 header when making HTTP requests to example.com, www.example.com, and 541 www.corp.example.com. (Note that a leading %x2E ("."), if present, 542 is ignored even though that character is not permitted, but a 543 trailing %x2E ("."), if present, will cause the user agent to ignore 544 the attribute.) If the server omits the Domain attribute, the user 545 agent will return the cookie only to the origin server. 547 WARNING: Some existing user agents treat an absent Domain attribute 548 as if the Domain attribute were present and contained the current 549 host name. For example, if example.com returns a Set-Cookie header 550 without a Domain attribute, these user agents will erroneously send 551 the cookie to www.example.com as well. 553 The user agent will reject cookies unless the Domain attribute 554 specifies a scope for the cookie that would include the origin 555 server. For example, the user agent will accept a cookie with a 556 Domain attribute of "example.com" or of "foo.example.com" from 557 foo.example.com, but the user agent will not accept a cookie with a 558 Domain attribute of "bar.example.com" or of "baz.foo.example.com". 560 NOTE: For security reasons, many user agents are configured to reject 561 Domain attributes that correspond to "public suffixes". For example, 562 some user agents will reject Domain attributes of "com" or "co.uk". 563 (See Section 5.4 for more information.) 565 4.1.2.4. The Path Attribute 567 The scope of each cookie is limited to a set of paths, controlled by 568 the Path attribute. If the server omits the Path attribute, the user 569 agent will use the "directory" of the request-uri's path component as 570 the default value. (See Section 5.1.4 for more details.) 572 The user agent will include the cookie in an HTTP request only if the 573 path portion of the request-uri matches (or is a subdirectory of) the 574 cookie's Path attribute, where the %x2F ("/") character is 575 interpreted as a directory separator. 577 Although seemingly useful for isolating cookies between different 578 paths within a given host, the Path attribute cannot be relied upon 579 for security (see Section 8). 581 4.1.2.5. The Secure Attribute 583 The Secure attribute limits the scope of the cookie to "secure" 584 channels (where "secure" is defined by the user agent). When a 585 cookie has the Secure attribute, the user agent will include the 586 cookie in an HTTP request only if the request is transmitted over a 587 secure channel (typically HTTP over Transport Layer Security (TLS) 588 [RFC2818]). 590 Although seemingly useful for protecting cookies from active network 591 attackers, the Secure attribute protects only the cookie's 592 confidentiality. An active network attacker can overwrite Secure 593 cookies from an insecure channel, disrupting their integrity (see 594 Section 8.6 for more details). 596 4.1.2.6. The HttpOnly Attribute 598 The HttpOnly attribute limits the scope of the cookie to HTTP 599 requests. In particular, the attribute instructs the user agent to 600 omit the cookie when providing access to cookies via "non-HTTP" APIs 601 (such as a web browser API that exposes cookies to scripts). 603 Note that the HttpOnly attribute is independent of the Secure 604 attribute: a cookie can have both the HttpOnly and the Secure 605 attribute. 607 4.1.2.7. The SameSite Attribute 609 The "SameSite" attribute limits the scope of the cookie such that it 610 will only be attached to requests if those requests are same-site, as 611 defined by the algorithm in Section 5.2. For example, requests for 612 "https://example.com/sekrit-image" will attach same-site cookies if 613 and only if initiated from a context whose "site for cookies" is 614 "example.com". 616 If the "SameSite" attribute's value is "Strict", the cookie will only 617 be sent along with "same-site" requests. If the value is "Lax", the 618 cookie will be sent with same-site requests, and with "cross-site" 619 top-level navigations, as described in Section 5.3.7.1. If the 620 "SameSite" attribute's value is neither of these, the cookie will be 621 ignored. 623 4.1.3. Cookie Name Prefixes 625 Section 8.5 and Section 8.6 of this document spell out some of the 626 drawbacks of cookies' historical implementation. In particular, it 627 is impossible for a server to have confidence that a given cookie was 628 set with a particular set of attributes. In order to provide such 629 confidence in a backwards-compatible way, two common sets of 630 requirements can be inferred from the first few characters of the 631 cookie's name. 633 The normative requirements for the prefixes described below are 634 detailed in the storage model algorithm defined in Section 5.4. 636 4.1.3.1. The "__Secure-" Prefix 638 If a cookie's name begins with a case-sensitive match for the string 639 "__Secure-", then the cookie will have been set with a "Secure" 640 attribute. 642 For example, the following "Set-Cookie" header would be rejected by a 643 conformant user agent, as it does not have a "Secure" attribute. 645 Set-Cookie: __Secure-SID=12345; Domain=example.com 647 Whereas the following "Set-Cookie" header would be accepted: 649 Set-Cookie: __Secure-SID=12345; Domain=example.com; Secure 651 4.1.3.2. The "__Host-" Prefix 653 If a cookie's name begins with a case-sensitive match for the string 654 "__Host-", then the cookie will have been set with a "Secure" 655 attribute, a "Path" attribute with a value of "/", and no "Domain" 656 attribute. 658 This combination yields a cookie that hews as closely as a cookie can 659 to treating the origin as a security boundary. The lack of a 660 "Domain" attribute ensures that the cookie's "host-only-flag" is 661 true, locking the cookie to a particular host, rather than allowing 662 it to span subdomains. Setting the "Path" to "/" means that the 663 cookie is effective for the entire host, and won't be overridden for 664 specific paths. The "Secure" attribute ensures that the cookie is 665 unaltered by non-secure origins, and won't span protocols. 667 Ports are the only piece of the origin model that "__Host-" cookies 668 continue to ignore. 670 For example, the following cookies would always be rejected: 672 Set-Cookie: __Host-SID=12345 673 Set-Cookie: __Host-SID=12345; Secure 674 Set-Cookie: __Host-SID=12345; Domain=example.com 675 Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/ 676 Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/ 678 While the would be accepted if set from a secure origin (e.g. 679 "https://example.com/"), and rejected otherwise: 681 Set-Cookie: __Host-SID=12345; Secure; Path=/ 683 4.2. Cookie 685 4.2.1. Syntax 687 The user agent sends stored cookies to the origin server in the 688 Cookie header. If the server conforms to the requirements in 689 Section 4.1 (and the user agent conforms to the requirements in 690 Section 5), the user agent will send a Cookie header that conforms to 691 the following grammar: 693 cookie-header = "Cookie:" OWS cookie-string OWS 694 cookie-string = cookie-pair *( ";" SP cookie-pair ) 696 4.2.2. Semantics 698 Each cookie-pair represents a cookie stored by the user agent. The 699 cookie-pair contains the cookie-name and cookie-value the user agent 700 received in the Set-Cookie header. 702 Notice that the cookie attributes are not returned. In particular, 703 the server cannot determine from the Cookie header alone when a 704 cookie will expire, for which hosts the cookie is valid, for which 705 paths the cookie is valid, or whether the cookie was set with the 706 Secure or HttpOnly attributes. 708 The semantics of individual cookies in the Cookie header are not 709 defined by this document. Servers are expected to imbue these 710 cookies with application-specific semantics. 712 Although cookies are serialized linearly in the Cookie header, 713 servers SHOULD NOT rely upon the serialization order. In particular, 714 if the Cookie header contains two cookies with the same name (e.g., 715 that were set with different Path or Domain attributes), servers 716 SHOULD NOT rely upon the order in which these cookies appear in the 717 header. 719 5. User Agent Requirements 721 This section specifies the Cookie and Set-Cookie headers in 722 sufficient detail that a user agent implementing these requirements 723 precisely can interoperate with existing servers (even those that do 724 not conform to the well-behaved profile described in Section 4). 726 A user agent could enforce more restrictions than those specified 727 herein (e.g., for the sake of improved security); however, 728 experiments have shown that such strictness reduces the likelihood 729 that a user agent will be able to interoperate with existing servers. 731 5.1. Subcomponent Algorithms 733 This section defines some algorithms used by user agents to process 734 specific subcomponents of the Cookie and Set-Cookie headers. 736 5.1.1. Dates 738 The user agent MUST use an algorithm equivalent to the following 739 algorithm to parse a cookie-date. Note that the various boolean 740 flags defined as a part of the algorithm (i.e., found-time, found- 741 day-of-month, found-month, found-year) are initially "not set". 743 1. Using the grammar below, divide the cookie-date into date-tokens. 745 cookie-date = *delimiter date-token-list *delimiter 746 date-token-list = date-token *( 1*delimiter date-token ) 747 date-token = 1*non-delimiter 749 delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E 750 non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF 751 non-digit = %x00-2F / %x3A-FF 753 day-of-month = 1*2DIGIT [ non-digit *OCTET ] 754 month = ( "jan" / "feb" / "mar" / "apr" / 755 "may" / "jun" / "jul" / "aug" / 756 "sep" / "oct" / "nov" / "dec" ) *OCTET 757 year = 2*4DIGIT [ non-digit *OCTET ] 758 time = hms-time [ non-digit *OCTET ] 759 hms-time = time-field ":" time-field ":" time-field 760 time-field = 1*2DIGIT 762 2. Process each date-token sequentially in the order the date-tokens 763 appear in the cookie-date: 765 1. If the found-time flag is not set and the token matches the 766 time production, set the found-time flag and set the hour- 767 value, minute-value, and second-value to the numbers denoted 768 by the digits in the date-token, respectively. Skip the 769 remaining sub-steps and continue to the next date-token. 771 2. If the found-day-of-month flag is not set and the date-token 772 matches the day-of-month production, set the found-day-of- 773 month flag and set the day-of-month-value to the number 774 denoted by the date-token. Skip the remaining sub-steps and 775 continue to the next date-token. 777 3. If the found-month flag is not set and the date-token matches 778 the month production, set the found-month flag and set the 779 month-value to the month denoted by the date-token. Skip the 780 remaining sub-steps and continue to the next date-token. 782 4. If the found-year flag is not set and the date-token matches 783 the year production, set the found-year flag and set the 784 year-value to the number denoted by the date-token. Skip the 785 remaining sub-steps and continue to the next date-token. 787 3. If the year-value is greater than or equal to 70 and less than or 788 equal to 99, increment the year-value by 1900. 790 4. If the year-value is greater than or equal to 0 and less than or 791 equal to 69, increment the year-value by 2000. 793 1. NOTE: Some existing user agents interpret two-digit years 794 differently. 796 5. Abort these steps and fail to parse the cookie-date if: 798 * at least one of the found-day-of-month, found-month, found- 799 year, or found-time flags is not set, 801 * the day-of-month-value is less than 1 or greater than 31, 803 * the year-value is less than 1601, 805 * the hour-value is greater than 23, 807 * the minute-value is greater than 59, or 809 * the second-value is greater than 59. 811 (Note that leap seconds cannot be represented in this syntax.) 813 6. Let the parsed-cookie-date be the date whose day-of-month, month, 814 year, hour, minute, and second (in UTC) are the day-of-month- 815 value, the month-value, the year-value, the hour-value, the 816 minute-value, and the second-value, respectively. If no such 817 date exists, abort these steps and fail to parse the cookie-date. 819 7. Return the parsed-cookie-date as the result of this algorithm. 821 5.1.2. Canonicalized Host Names 823 A canonicalized host name is the string generated by the following 824 algorithm: 826 1. Convert the host name to a sequence of individual domain name 827 labels. 829 2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, 830 to an A-label (see Section 2.3.2.1 of [RFC5890] for the former 831 and latter), or to a "punycode label" (a label resulting from the 832 "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate 833 (see Section 6.3 of this specification). 835 3. Concatenate the resulting labels, separated by a %x2E (".") 836 character. 838 5.1.3. Domain Matching 840 A string domain-matches a given domain string if at least one of the 841 following conditions hold: 843 o The domain string and the string are identical. (Note that both 844 the domain string and the string will have been canonicalized to 845 lower case at this point.) 847 o All of the following conditions hold: 849 * The domain string is a suffix of the string. 851 * The last character of the string that is not included in the 852 domain string is a %x2E (".") character. 854 * The string is a host name (i.e., not an IP address). 856 5.1.4. Paths and Path-Match 858 The user agent MUST use an algorithm equivalent to the following 859 algorithm to compute the default-path of a cookie: 861 1. Let uri-path be the path portion of the request-uri if such a 862 portion exists (and empty otherwise). For example, if the 863 request-uri contains just a path (and optional query string), 864 then the uri-path is that path (without the %x3F ("?") character 865 or query string), and if the request-uri contains a full 866 absoluteURI, the uri-path is the path component of that URI. 868 2. If the uri-path is empty or if the first character of the uri- 869 path is not a %x2F ("/") character, output %x2F ("/") and skip 870 the remaining steps. 872 3. If the uri-path contains no more than one %x2F ("/") character, 873 output %x2F ("/") and skip the remaining step. 875 4. Output the characters of the uri-path from the first character up 876 to, but not including, the right-most %x2F ("/"). 878 A request-path path-matches a given cookie-path if at least one of 879 the following conditions holds: 881 o The cookie-path and the request-path are identical. 883 Note that this differs from the rules in [RFC3986] for equivalence 884 of the path component, and hence two equivalent paths can have 885 different cookies. 887 o The cookie-path is a prefix of the request-path, and the last 888 character of the cookie-path is %x2F ("/"). 890 o The cookie-path is a prefix of the request-path, and the first 891 character of the request-path that is not included in the cookie- 892 path is a %x2F ("/") character. 894 5.2. "Same-site" and "cross-site" Requests 896 A request is "same-site" if its target's URI's origin's registered 897 domain is an exact match for the request's client's "site for 898 cookies", or if the request has no client. The request is otherwise 899 "cross-site". 901 For a given request ("request"), the following algorithm returns 902 "same-site" or "cross-site": 904 1. If "request"'s client is "null", return "same-site". 906 Note that this is the case for navigation triggered by the user 907 directly (e.g. by typing directly into a user agent's address 908 bar). 910 2. Let "site" be "request"'s client's "site for cookies" (as defined 911 in the following sections). 913 3. Let "target" be the registered domain of "request"'s current url. 915 4. If "site" is an exact match for "target", return "same-site". 917 5. Return "cross-site". 919 The request's client's "site for cookies" is calculated depending 920 upon its client's type, as described in the following subsections: 922 5.2.1. Document-based requests 924 The URI displayed in a user agent's address bar is the only security 925 context directly exposed to users, and therefore the only signal 926 users can reasonably rely upon to determine whether or not they trust 927 a particular website. The registered domain of that URI's origin 928 represents the context in which a user most likely believes 929 themselves to be interacting. We'll label this domain the "top-level 930 site". 932 For a document displayed in a top-level browsing context, we can stop 933 here: the document's "site for cookies" is the top-level site. 935 For documents which are displayed in nested browsing contexts, we 936 need to audit the origins of each of a document's ancestor browsing 937 contexts' active documents in order to account for the "multiple- 938 nested scenarios" described in Section 4 of [RFC7034]. These 939 document's "site for cookies" is the top-level site if and only if 940 the document and each of its ancestor documents' origins have the 941 same registered domain as the top-level site. Otherwise its "site 942 for cookies" is the empty string. 944 Given a Document ("document"), the following algorithm returns its 945 "site for cookies" (either a registered domain, or the empty string): 947 1. Let "top-document" be the active document in "document"'s 948 browsing context's top-level browsing context. 950 2. Let "top-origin" be the origin of "top-document"'s URI if "top- 951 document"'s sandboxed origin browsing context flag is set, and 952 "top-document"'s origin otherwise. 954 3. Let "documents" be a list containing "document" and each of 955 "document"'s ancestor browsing contexts' active documents. 957 4. For each "item" in "documents": 959 1. Let "origin" be the origin of "item"'s URI if "item"'s 960 sandboxed origin browsing context flag is set, and "item"'s 961 origin otherwise. 963 2. If "origin"'s host's registered domain is not an exact match 964 for "top-origin"'s host's registered domain, return the empty 965 string. 967 5. Return "top-origin"'s host's registered domain. 969 5.2.2. Worker-based requests 971 Worker-driven requests aren't as clear-cut as document-driven 972 requests, as there isn't a clear link between a top-level browsing 973 context and a worker. This is especially true for Service Workers 974 [SERVICE-WORKERS], which may execute code in the background, without 975 any document visible at all. 977 Note: The descriptions below assume that workers must be same-origin 978 with the documents that instantiate them. If this invariant changes, 979 we'll need to take the worker's script's URI into account when 980 determining their status. 982 5.2.2.1. Dedicated and Shared Workers 984 Dedicated workers are simple, as each dedicated worker is bound to 985 one and only one document. Requests generated from a dedicated 986 worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define 987 their "site for cookies" as that document's "site for cookies". 989 Shared workers may be bound to multiple documents at once. As it is 990 quite possible for those documents to have distinct "site for cookie" 991 values, the worker's "site for cookies" will be the empty string in 992 cases where the values diverge, and the shared value in cases where 993 the values agree. 995 Given a WorkerGlobalScope ("worker"), the following algorithm returns 996 its "site for cookies" (either a registered domain, or the empty 997 string): 999 1. Let "site" be "worker"'s origin's host's registered domain. 1001 2. For each "document" in "worker"'s Documents: 1003 1. Let "document-site" be "document"'s "site for cookies" (as 1004 defined in Section 5.2.1). 1006 2. If "document-site" is not an exact match for "site", return 1007 the empty string. 1009 3. Return "site". 1011 5.2.2.2. Service Workers 1013 Service Workers are more complicated, as they act as a completely 1014 separate execution context with only tangential relationship to the 1015 Document which registered them. 1017 Requests which simply pass through a service worker will be handled 1018 as described above: the request's client will be the Document or 1019 Worker which initiated the request, and its "site for cookies" will 1020 be those defined in Section 5.2.1 and Section 5.2.2.1 1022 Requests which are initiated by the Service Worker itself (via a 1023 direct call to "fetch()", for instance), on the other hand, will have 1024 a client which is a ServiceWorkerGlobalScope. Its "site for cookies" 1025 will be the registered domain of the Service Worker's URI. 1027 Given a ServiceWorkerGlobalScope ("worker"), the following algorithm 1028 returns its "site for cookies" (either a registered domain, or the 1029 empty string): 1031 1. Return "worker"'s origin's host's registered domain. 1033 5.3. The Set-Cookie Header 1035 When a user agent receives a Set-Cookie header field in an HTTP 1036 response, the user agent MAY ignore the Set-Cookie header field in 1037 its entirety. For example, the user agent might wish to block 1038 responses to "third-party" requests from setting cookies (see 1039 Section 7.1). 1041 If the user agent does not ignore the Set-Cookie header field in its 1042 entirety, the user agent MUST parse the field-value of the Set-Cookie 1043 header field as a set-cookie-string (defined below). 1045 NOTE: The algorithm below is more permissive than the grammar in 1046 Section 4.1. For example, the algorithm strips leading and trailing 1047 whitespace from the cookie name and value (but maintains internal 1048 whitespace), whereas the grammar in Section 4.1 forbids whitespace in 1049 these positions. User agents use this algorithm so as to 1050 interoperate with servers that do not follow the recommendations in 1051 Section 4. 1053 A user agent MUST use an algorithm equivalent to the following 1054 algorithm to parse a set-cookie-string: 1056 1. If the set-cookie-string contains a %x3B (";") character: 1058 1. The name-value-pair string consists of the characters up to, 1059 but not including, the first %x3B (";"), and the unparsed- 1060 attributes consist of the remainder of the set-cookie-string 1061 (including the %x3B (";") in question). 1063 Otherwise: 1065 1. The name-value-pair string consists of all the characters 1066 contained in the set-cookie-string, and the unparsed- 1067 attributes is the empty string. 1069 2. If the name-value-pair string lacks a %x3D ("=") character, 1070 ignore the set-cookie-string entirely. 1072 3. The (possibly empty) name string consists of the characters up 1073 to, but not including, the first %x3D ("=") character, and the 1074 (possibly empty) value string consists of the characters after 1075 the first %x3D ("=") character. 1077 4. Remove any leading or trailing WSP characters from the name 1078 string and the value string. 1080 5. If the name string is empty, ignore the set-cookie-string 1081 entirely. 1083 6. The cookie-name is the name string, and the cookie-value is the 1084 value string. 1086 The user agent MUST use an algorithm equivalent to the following 1087 algorithm to parse the unparsed-attributes: 1089 1. If the unparsed-attributes string is empty, skip the rest of 1090 these steps. 1092 2. Discard the first character of the unparsed-attributes (which 1093 will be a %x3B (";") character). 1095 3. If the remaining unparsed-attributes contains a %x3B (";") 1096 character: 1098 1. Consume the characters of the unparsed-attributes up to, but 1099 not including, the first %x3B (";") character. 1101 Otherwise: 1103 1. Consume the remainder of the unparsed-attributes. 1105 Let the cookie-av string be the characters consumed in this step. 1107 4. If the cookie-av string contains a %x3D ("=") character: 1109 1. The (possibly empty) attribute-name string consists of the 1110 characters up to, but not including, the first %x3D ("=") 1111 character, and the (possibly empty) attribute-value string 1112 consists of the characters after the first %x3D ("=") 1113 character. 1115 Otherwise: 1117 1. The attribute-name string consists of the entire cookie-av 1118 string, and the attribute-value string is empty. 1120 5. Remove any leading or trailing WSP characters from the attribute- 1121 name string and the attribute-value string. 1123 6. Process the attribute-name and attribute-value according to the 1124 requirements in the following subsections. (Notice that 1125 attributes with unrecognized attribute-names are ignored.) 1127 7. Return to Step 1 of this algorithm. 1129 When the user agent finishes parsing the set-cookie-string, the user 1130 agent is said to "receive a cookie" from the request-uri with name 1131 cookie-name, value cookie-value, and attributes cookie-attribute- 1132 list. (See Section 5.4 for additional requirements triggered by 1133 receiving a cookie.) 1135 5.3.1. The Expires Attribute 1137 If the attribute-name case-insensitively matches the string 1138 "Expires", the user agent MUST process the cookie-av as follows. 1140 1. Let the expiry-time be the result of parsing the attribute-value 1141 as cookie-date (see Section 5.1.1). 1143 2. If the attribute-value failed to parse as a cookie date, ignore 1144 the cookie-av. 1146 3. If the expiry-time is later than the last date the user agent can 1147 represent, the user agent MAY replace the expiry-time with the 1148 last representable date. 1150 4. If the expiry-time is earlier than the earliest date the user 1151 agent can represent, the user agent MAY replace the expiry-time 1152 with the earliest representable date. 1154 5. Append an attribute to the cookie-attribute-list with an 1155 attribute-name of Expires and an attribute-value of expiry-time. 1157 5.3.2. The Max-Age Attribute 1159 If the attribute-name case-insensitively matches the string "Max- 1160 Age", the user agent MUST process the cookie-av as follows. 1162 1. If the first character of the attribute-value is not a DIGIT or a 1163 "-" character, ignore the cookie-av. 1165 2. If the remainder of attribute-value contains a non-DIGIT 1166 character, ignore the cookie-av. 1168 3. Let delta-seconds be the attribute-value converted to an integer. 1170 4. If delta-seconds is less than or equal to zero (0), let expiry- 1171 time be the earliest representable date and time. Otherwise, let 1172 the expiry-time be the current date and time plus delta-seconds 1173 seconds. 1175 5. Append an attribute to the cookie-attribute-list with an 1176 attribute-name of Max-Age and an attribute-value of expiry-time. 1178 5.3.3. The Domain Attribute 1180 If the attribute-name case-insensitively matches the string "Domain", 1181 the user agent MUST process the cookie-av as follows. 1183 1. If the attribute-value is empty, the behavior is undefined. 1184 However, the user agent SHOULD ignore the cookie-av entirely. 1186 2. If the first character of the attribute-value string is %x2E 1187 ("."): 1189 1. Let cookie-domain be the attribute-value without the leading 1190 %x2E (".") character. 1192 Otherwise: 1194 1. Let cookie-domain be the entire attribute-value. 1196 3. Convert the cookie-domain to lower case. 1198 4. Append an attribute to the cookie-attribute-list with an 1199 attribute-name of Domain and an attribute-value of cookie-domain. 1201 5.3.4. The Path Attribute 1203 If the attribute-name case-insensitively matches the string "Path", 1204 the user agent MUST process the cookie-av as follows. 1206 1. If the attribute-value is empty or if the first character of the 1207 attribute-value is not %x2F ("/"): 1209 1. Let cookie-path be the default-path. 1211 Otherwise: 1213 1. Let cookie-path be the attribute-value. 1215 2. Append an attribute to the cookie-attribute-list with an 1216 attribute-name of Path and an attribute-value of cookie-path. 1218 5.3.5. The Secure Attribute 1220 If the attribute-name case-insensitively matches the string "Secure", 1221 the user agent MUST append an attribute to the cookie-attribute-list 1222 with an attribute-name of Secure and an empty attribute-value. 1224 5.3.6. The HttpOnly Attribute 1226 If the attribute-name case-insensitively matches the string 1227 "HttpOnly", the user agent MUST append an attribute to the cookie- 1228 attribute-list with an attribute-name of HttpOnly and an empty 1229 attribute-value. 1231 5.3.7. The SameSite Attribute 1233 If the attribute-name case-insensitively matches the string 1234 "SameSite", the user agent MUST process the cookie-av as follows: 1236 1. If cookie-av's attribute-value is not a case-insensitive match 1237 for "Strict" or "Lax", ignore the "cookie-av". 1239 2. Let "enforcement" be "Lax" if cookie-av's attribute-value is a 1240 case-insensitive match for "Lax", and "Strict" otherwise. 1242 3. Append an attribute to the cookie-attribute-list with an 1243 attribute-name of "SameSite" and an attribute-value of 1244 "enforcement". 1246 5.3.7.1. "Strict" and "Lax" enforcement 1248 Same-site cookies in "Strict" enforcement mode will not be sent along 1249 with top-level navigations which are triggered from a cross-site 1250 document context. As discussed in Section 8.8.2, this might or might 1251 not be compatible with existing session management systems. In the 1252 interests of providing a drop-in mechanism that mitigates the risk of 1253 CSRF attacks, developers may set the "SameSite" attribute in a "Lax" 1254 enforcement mode that carves out an exception which sends same-site 1255 cookies along with cross-site requests if and only if they are top- 1256 level navigations which use a "safe" (in the [RFC7231] sense) HTTP 1257 method. 1259 Lax enforcement provides reasonable defense in depth against CSRF 1260 attacks that rely on unsafe HTTP methods (like "POST"), but does not 1261 offer a robust defense against CSRF as a general category of attack: 1263 1. Attackers can still pop up new windows or trigger top-level 1264 navigations in order to create a "same-site" request (as 1265 described in section 2.1), which is only a speedbump along the 1266 road to exploitation. 1268 2. Features like "" [prerendering] can be 1269 exploited to create "same-site" requests without the risk of user 1270 detection. 1272 When possible, developers should use a session management mechanism 1273 such as that described in Section 8.8.2 to mitigate the risk of CSRF 1274 more completely. 1276 5.4. Storage Model 1278 The user agent stores the following fields about each cookie: name, 1279 value, expiry-time, domain, path, creation-time, last-access-time, 1280 persistent-flag, host-only-flag, secure-only-flag, http-only-flag, 1281 and same-site-flag. 1283 When the user agent "receives a cookie" from a request-uri with name 1284 cookie-name, value cookie-value, and attributes cookie-attribute- 1285 list, the user agent MUST process the cookie as follows: 1287 1. A user agent MAY ignore a received cookie in its entirety. For 1288 example, the user agent might wish to block receiving cookies 1289 from "third-party" responses or the user agent might not wish to 1290 store cookies that exceed some size. 1292 2. Create a new cookie with name cookie-name, value cookie-value. 1293 Set the creation-time and the last-access-time to the current 1294 date and time. 1296 3. If the cookie-attribute-list contains an attribute with an 1297 attribute-name of "Max-Age": 1299 1. Set the cookie's persistent-flag to true. 1301 2. Set the cookie's expiry-time to attribute-value of the last 1302 attribute in the cookie-attribute-list with an attribute- 1303 name of "Max-Age". 1305 Otherwise, if the cookie-attribute-list contains an attribute 1306 with an attribute-name of "Expires" (and does not contain an 1307 attribute with an attribute-name of "Max-Age"): 1309 1. Set the cookie's persistent-flag to true. 1311 2. Set the cookie's expiry-time to attribute-value of the last 1312 attribute in the cookie-attribute-list with an attribute- 1313 name of "Expires". 1315 Otherwise: 1317 1. Set the cookie's persistent-flag to false. 1319 2. Set the cookie's expiry-time to the latest representable 1320 date. 1322 4. If the cookie-attribute-list contains an attribute with an 1323 attribute-name of "Domain": 1325 1. Let the domain-attribute be the attribute-value of the last 1326 attribute in the cookie-attribute-list with an attribute- 1327 name of "Domain". 1329 Otherwise: 1331 1. Let the domain-attribute be the empty string. 1333 5. If the user agent is configured to reject "public suffixes" and 1334 the domain-attribute is a public suffix: 1336 1. If the domain-attribute is identical to the canonicalized 1337 request-host: 1339 1. Let the domain-attribute be the empty string. 1341 Otherwise: 1343 1. Ignore the cookie entirely and abort these steps. 1345 NOTE: A "public suffix" is a domain that is controlled by a 1346 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 1347 This step is essential for preventing attacker.com from 1348 disrupting the integrity of example.com by setting a cookie with 1349 a Domain attribute of "com". Unfortunately, the set of public 1350 suffixes (also known as "registry controlled domains") changes 1351 over time. If feasible, user agents SHOULD use an up-to-date 1352 public suffix list, such as the one maintained by the Mozilla 1353 project at http://publicsuffix.org/ . 1355 6. If the domain-attribute is non-empty: 1357 1. If the canonicalized request-host does not domain-match the 1358 domain-attribute: 1360 1. Ignore the cookie entirely and abort these steps. 1362 Otherwise: 1364 1. Set the cookie's host-only-flag to false. 1366 2. Set the cookie's domain to the domain-attribute. 1368 Otherwise: 1370 1. Set the cookie's host-only-flag to true. 1372 2. Set the cookie's domain to the canonicalized request-host. 1374 7. If the cookie-attribute-list contains an attribute with an 1375 attribute-name of "Path", set the cookie's path to attribute- 1376 value of the last attribute in the cookie-attribute-list with an 1377 attribute-name of "Path". Otherwise, set the cookie's path to 1378 the default-path of the request-uri. 1380 8. If the cookie-attribute-list contains an attribute with an 1381 attribute-name of "Secure", set the cookie's secure-only-flag to 1382 true. Otherwise, set the cookie's secure-only-flag to false. 1384 9. If the scheme component of the request-uri does not denote a 1385 "secure" protocol (as defined by the user agent), and the 1386 cookie's secure-only-flag is true, then abort these steps and 1387 ignore the cookie entirely. 1389 10. If the cookie-attribute-list contains an attribute with an 1390 attribute-name of "HttpOnly", set the cookie's http-only-flag to 1391 true. Otherwise, set the cookie's http-only-flag to false. 1393 11. If the cookie was received from a "non-HTTP" API and the 1394 cookie's http-only-flag is true, abort these steps and ignore 1395 the cookie entirely. 1397 12. If the cookie's secure-only-flag is not set, and the scheme 1398 component of request-uri does not denote a "secure" protocol, 1399 then abort these steps and ignore the cookie entirely if the 1400 cookie store contains one or more cookies that meet all of the 1401 following criteria: 1403 1. Their name matches the name of the newly-created cookie. 1405 2. Their secure-only-flag is true. 1407 3. Their domain domain-matches the domain of the newly-created 1408 cookie, or vice-versa. 1410 4. The path of the newly-created cookie path-matches the path 1411 of the existing cookie. 1413 Note: The path comparison is not symmetric, ensuring only that a 1414 newly-created, non-secure cookie does not overlay an existing 1415 secure cookie, providing some mitigation against cookie-fixing 1416 attacks. That is, given an existing secure cookie named 'a' 1417 with a path of '/login', a non-secure cookie named 'a' could be 1418 set for a path of '/' or '/foo', but not for a path of '/login' 1419 or '/login/en'. 1421 13. If the cookie-attribute-list contains an attribute with an 1422 attribute-name of "SameSite", set the cookie's same-site-flag to 1423 attribute-value (i.e. either "Strict" or "Lax"). Otherwise, set 1424 the cookie's same-site-flag to "None". 1426 14. If the cookie's "same-site-flag" is not "None", and the cookie 1427 is being set from a context whose "site for cookies" is not an 1428 exact match for request-uri's host's registered domain, then 1429 abort these steps and ignore the newly created cookie entirely. 1431 15. If the cookie-name begins with a case-sensitive match for the 1432 string "__Secure-", abort these steps and ignore the cookie 1433 entirely unless the cookie's secure-only-flag is true. 1435 16. If the cookie-name begins with a case-sensitive match for the 1436 string "__Host-", abort these steps and ignore the cookie 1437 entirely unless the cookie meets all the following criteria: 1439 1. The cookie's secure-only-flag is true. 1441 2. The cookie's host-only-flag is true. 1443 3. The cookie-attribute-list contains an attribute with an 1444 attribute-name of "Path", and the cookie's path is "/". 1446 17. If the cookie store contains a cookie with the same name, 1447 domain, and path as the newly-created cookie: 1449 1. Let old-cookie be the existing cookie with the same name, 1450 domain, and path as the newly-created cookie. (Notice that 1451 this algorithm maintains the invariant that there is at most 1452 one such cookie.) 1454 2. If the newly-created cookie was received from a "non-HTTP" 1455 API and the old-cookie's http-only-flag is true, abort these 1456 steps and ignore the newly created cookie entirely. 1458 3. Update the creation-time of the newly-created cookie to 1459 match the creation-time of the old-cookie. 1461 4. Remove the old-cookie from the cookie store. 1463 18. Insert the newly-created cookie into the cookie store. 1465 A cookie is "expired" if the cookie has an expiry date in the past. 1467 The user agent MUST evict all expired cookies from the cookie store 1468 if, at any time, an expired cookie exists in the cookie store. 1470 At any time, the user agent MAY "remove excess cookies" from the 1471 cookie store if the number of cookies sharing a domain field exceeds 1472 some implementation-defined upper bound (such as 50 cookies). 1474 At any time, the user agent MAY "remove excess cookies" from the 1475 cookie store if the cookie store exceeds some predetermined upper 1476 bound (such as 3000 cookies). 1478 When the user agent removes excess cookies from the cookie store, the 1479 user agent MUST evict cookies in the following priority order: 1481 1. Expired cookies. 1483 2. Cookies whose secure-only-flag is not set, and which share a 1484 domain field with more than a predetermined number of other 1485 cookies. 1487 3. Cookies that share a domain field with more than a predetermined 1488 number of other cookies. 1490 4. All cookies. 1492 If two cookies have the same removal priority, the user agent MUST 1493 evict the cookie with the earliest last-access date first. 1495 When "the current session is over" (as defined by the user agent), 1496 the user agent MUST remove from the cookie store all cookies with the 1497 persistent-flag set to false. 1499 5.5. The Cookie Header 1501 The user agent includes stored cookies in the Cookie HTTP request 1502 header. 1504 When the user agent generates an HTTP request, the user agent MUST 1505 NOT attach more than one Cookie header field. 1507 A user agent MAY omit the Cookie header in its entirety. For 1508 example, the user agent might wish to block sending cookies during 1509 "third-party" requests from setting cookies (see Section 7.1). 1511 If the user agent does attach a Cookie header field to an HTTP 1512 request, the user agent MUST send the cookie-string (defined below) 1513 as the value of the header field. 1515 The user agent MUST use an algorithm equivalent to the following 1516 algorithm to compute the cookie-string from a cookie store and a 1517 request-uri: 1519 1. Let cookie-list be the set of cookies from the cookie store that 1520 meets all of the following requirements: 1522 * Either: 1524 + The cookie's host-only-flag is true and the canonicalized 1525 request-host is identical to the cookie's domain. 1527 Or: 1529 + The cookie's host-only-flag is false and the canonicalized 1530 request-host domain-matches the cookie's domain. 1532 * The request-uri's path path-matches the cookie's path. 1534 * If the cookie's secure-only-flag is true, then the request- 1535 uri's scheme must denote a "secure" protocol (as defined by 1536 the user agent). 1538 NOTE: The notion of a "secure" protocol is not defined by this 1539 document. Typically, user agents consider a protocol secure 1540 if the protocol makes use of transport-layer security, such as 1541 SSL or TLS. For example, most user agents consider "https" to 1542 be a scheme that denotes a secure protocol. 1544 * If the cookie's http-only-flag is true, then exclude the 1545 cookie if the cookie-string is being generated for a "non- 1546 HTTP" API (as defined by the user agent). 1548 * If the cookie's same-site-flag is not "None", and the HTTP 1549 request is cross-site (as defined in Section 5.2) then exclude 1550 the cookie unless all of the following statements hold: 1552 1. The same-site-flag is "Lax" 1554 2. The HTTP request's method is "safe". 1556 3. The HTTP request's target browsing context is a top-level 1557 browsing context. 1559 2. The user agent SHOULD sort the cookie-list in the following 1560 order: 1562 * Cookies with longer paths are listed before cookies with 1563 shorter paths. 1565 * Among cookies that have equal-length path fields, cookies with 1566 earlier creation-times are listed before cookies with later 1567 creation-times. 1569 NOTE: Not all user agents sort the cookie-list in this order, but 1570 this order reflects common practice when this document was 1571 written, and, historically, there have been servers that 1572 (erroneously) depended on this order. 1574 3. Update the last-access-time of each cookie in the cookie-list to 1575 the current date and time. 1577 4. Serialize the cookie-list into a cookie-string by processing each 1578 cookie in the cookie-list in order: 1580 1. Output the cookie's name, the %x3D ("=") character, and the 1581 cookie's value. 1583 2. If there is an unprocessed cookie in the cookie-list, output 1584 the characters %x3B and %x20 ("; "). 1586 NOTE: Despite its name, the cookie-string is actually a sequence of 1587 octets, not a sequence of characters. To convert the cookie-string 1588 (or components thereof) into a sequence of characters (e.g., for 1589 presentation to the user), the user agent might wish to try using the 1590 UTF-8 character encoding [RFC3629] to decode the octet sequence. 1591 This decoding might fail, however, because not every sequence of 1592 octets is valid UTF-8. 1594 6. Implementation Considerations 1596 6.1. Limits 1598 Practical user agent implementations have limits on the number and 1599 size of cookies that they can store. General-use user agents SHOULD 1600 provide each of the following minimum capabilities: 1602 o At least 4096 bytes per cookie (as measured by the sum of the 1603 length of the cookie's name, value, and attributes). 1605 o At least 50 cookies per domain. 1607 o At least 3000 cookies total. 1609 Servers SHOULD use as few and as small cookies as possible to avoid 1610 reaching these implementation limits and to minimize network 1611 bandwidth due to the Cookie header being included in every request. 1613 Servers SHOULD gracefully degrade if the user agent fails to return 1614 one or more cookies in the Cookie header because the user agent might 1615 evict any cookie at any time on orders from the user. 1617 6.2. Application Programming Interfaces 1619 One reason the Cookie and Set-Cookie headers use such esoteric syntax 1620 is that many platforms (both in servers and user agents) provide a 1621 string-based application programming interface (API) to cookies, 1622 requiring application-layer programmers to generate and parse the 1623 syntax used by the Cookie and Set-Cookie headers, which many 1624 programmers have done incorrectly, resulting in interoperability 1625 problems. 1627 Instead of providing string-based APIs to cookies, platforms would be 1628 well-served by providing more semantic APIs. It is beyond the scope 1629 of this document to recommend specific API designs, but there are 1630 clear benefits to accepting an abstract "Date" object instead of a 1631 serialized date string. 1633 6.3. IDNA Dependency and Migration 1635 IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are 1636 differences between the two specifications, and thus there can be 1637 differences in processing (e.g., converting) domain name labels that 1638 have been registered under one from those registered under the other. 1639 There will be a transition period of some time during which 1640 IDNA2003-based domain name labels will exist in the wild. User 1641 agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] 1642 or [RFC5895] in order to facilitate their IDNA transition. If a user 1643 agent does not implement IDNA2008, the user agent MUST implement 1644 IDNA2003 [RFC3490]. 1646 7. Privacy Considerations 1648 Cookies are often criticized for letting servers track users. For 1649 example, a number of "web analytics" companies use cookies to 1650 recognize when a user returns to a web site or visits another web 1651 site. Although cookies are not the only mechanism servers can use to 1652 track users across HTTP requests, cookies facilitate tracking because 1653 they are persistent across user agent sessions and can be shared 1654 between hosts. 1656 7.1. Third-Party Cookies 1658 Particularly worrisome are so-called "third-party" cookies. In 1659 rendering an HTML document, a user agent often requests resources 1660 from other servers (such as advertising networks). These third-party 1661 servers can use cookies to track the user even if the user never 1662 visits the server directly. For example, if a user visits a site 1663 that contains content from a third party and then later visits 1664 another site that contains content from the same third party, the 1665 third party can track the user between the two sites. 1667 Given this risk to user privacy, some user agents restrict how third- 1668 party cookies behave, and those restrictions vary widly. For 1669 instance, user agents might block third-party cookies entirely by 1670 refusing to send Cookie headers or process Set-Cookie headers during 1671 third-party requests. They might take a less draconian approach by 1672 partitioning cookies based on the first-party context, sending one 1673 set of cookies to a given third party in one first-party context, and 1674 another to the same third party in another. 1676 This document grants user agents wide latitude to experiment with 1677 third-party cookie policies that balance the privacy and 1678 compatibility needs of their users. However, this document does not 1679 endorse any particular third-party cookie policy. 1681 Third-party cookie blocking policies are often ineffective at 1682 achieving their privacy goals if servers attempt to work around their 1683 restrictions to track users. In particular, two collaborating 1684 servers can often track users without using cookies at all by 1685 injecting identifying information into dynamic URLs. 1687 7.2. User Controls 1689 User agents SHOULD provide users with a mechanism for managing the 1690 cookies stored in the cookie store. For example, a user agent might 1691 let users delete all cookies received during a specified time period 1692 or all the cookies related to a particular domain. In addition, many 1693 user agents include a user interface element that lets users examine 1694 the cookies stored in their cookie store. 1696 User agents SHOULD provide users with a mechanism for disabling 1697 cookies. When cookies are disabled, the user agent MUST NOT include 1698 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1699 process Set-Cookie headers in inbound HTTP responses. 1701 Some user agents provide users the option of preventing persistent 1702 storage of cookies across sessions. When configured thusly, user 1703 agents MUST treat all received cookies as if the persistent-flag were 1704 set to false. Some popular user agents expose this functionality via 1705 "private browsing" mode [Aggarwal2010]. 1707 Some user agents provide users with the ability to approve individual 1708 writes to the cookie store. In many common usage scenarios, these 1709 controls generate a large number of prompts. However, some privacy- 1710 conscious users find these controls useful nonetheless. 1712 7.3. Expiration Dates 1714 Although servers can set the expiration date for cookies to the 1715 distant future, most user agents do not actually retain cookies for 1716 multiple decades. Rather than choosing gratuitously long expiration 1717 periods, servers SHOULD promote user privacy by selecting reasonable 1718 cookie expiration periods based on the purpose of the cookie. For 1719 example, a typical session identifier might reasonably be set to 1720 expire in two weeks. 1722 8. Security Considerations 1724 8.1. Overview 1726 Cookies have a number of security pitfalls. This section overviews a 1727 few of the more salient issues. 1729 In particular, cookies encourage developers to rely on ambient 1730 authority for authentication, often becoming vulnerable to attacks 1731 such as cross-site request forgery [CSRF]. Also, when storing 1732 session identifiers in cookies, developers often create session 1733 fixation vulnerabilities. 1735 Transport-layer encryption, such as that employed in HTTPS, is 1736 insufficient to prevent a network attacker from obtaining or altering 1737 a victim's cookies because the cookie protocol itself has various 1738 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1739 below). In addition, by default, cookies do not provide 1740 confidentiality or integrity from network attackers, even when used 1741 in conjunction with HTTPS. 1743 8.2. Ambient Authority 1745 A server that uses cookies to authenticate users can suffer security 1746 vulnerabilities because some user agents let remote parties issue 1747 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1748 forms). When issuing those requests, user agents attach cookies even 1749 if the remote party does not know the contents of the cookies, 1750 potentially letting the remote party exercise authority at an unwary 1751 server. 1753 Although this security concern goes by a number of names (e.g., 1754 cross-site request forgery, confused deputy), the issue stems from 1755 cookies being a form of ambient authority. Cookies encourage server 1756 operators to separate designation (in the form of URLs) from 1757 authorization (in the form of cookies). Consequently, the user agent 1758 might supply the authorization for a resource designated by the 1759 attacker, possibly causing the server or its clients to undertake 1760 actions designated by the attacker as though they were authorized by 1761 the user. 1763 Instead of using cookies for authorization, server operators might 1764 wish to consider entangling designation and authorization by treating 1765 URLs as capabilities. Instead of storing secrets in cookies, this 1766 approach stores secrets in URLs, requiring the remote entity to 1767 supply the secret itself. Although this approach is not a panacea, 1768 judicious application of these principles can lead to more robust 1769 security. 1771 8.3. Clear Text 1773 Unless sent over a secure channel (such as TLS), the information in 1774 the Cookie and Set-Cookie headers is transmitted in the clear. 1776 1. All sensitive information conveyed in these headers is exposed to 1777 an eavesdropper. 1779 2. A malicious intermediary could alter the headers as they travel 1780 in either direction, with unpredictable results. 1782 3. A malicious client could alter the Cookie header before 1783 transmission, with unpredictable results. 1785 Servers SHOULD encrypt and sign the contents of cookies (using 1786 whatever format the server desires) when transmitting them to the 1787 user agent (even when sending the cookies over a secure channel). 1788 However, encrypting and signing cookie contents does not prevent an 1789 attacker from transplanting a cookie from one user agent to another 1790 or from replaying the cookie at a later time. 1792 In addition to encrypting and signing the contents of every cookie, 1793 servers that require a higher level of security SHOULD use the Cookie 1794 and Set-Cookie headers only over a secure channel. When using 1795 cookies over a secure channel, servers SHOULD set the Secure 1796 attribute (see Section 4.1.2.5) for every cookie. If a server does 1797 not set the Secure attribute, the protection provided by the secure 1798 channel will be largely moot. 1800 For example, consider a webmail server that stores a session 1801 identifier in a cookie and is typically accessed over HTTPS. If the 1802 server does not set the Secure attribute on its cookies, an active 1803 network attacker can intercept any outbound HTTP request from the 1804 user agent and redirect that request to the webmail server over HTTP. 1805 Even if the webmail server is not listening for HTTP connections, the 1806 user agent will still include cookies in the request. The active 1807 network attacker can intercept these cookies, replay them against the 1808 server, and learn the contents of the user's email. If, instead, the 1809 server had set the Secure attribute on its cookies, the user agent 1810 would not have included the cookies in the clear-text request. 1812 8.4. Session Identifiers 1814 Instead of storing session information directly in a cookie (where it 1815 might be exposed to or replayed by an attacker), servers commonly 1816 store a nonce (or "session identifier") in a cookie. When the server 1817 receives an HTTP request with a nonce, the server can look up state 1818 information associated with the cookie using the nonce as a key. 1820 Using session identifier cookies limits the damage an attacker can 1821 cause if the attacker learns the contents of a cookie because the 1822 nonce is useful only for interacting with the server (unlike non- 1823 nonce cookie content, which might itself be sensitive). Furthermore, 1824 using a single nonce prevents an attacker from "splicing" together 1825 cookie content from two interactions with the server, which could 1826 cause the server to behave unexpectedly. 1828 Using session identifiers is not without risk. For example, the 1829 server SHOULD take care to avoid "session fixation" vulnerabilities. 1831 A session fixation attack proceeds in three steps. First, the 1832 attacker transplants a session identifier from his or her user agent 1833 to the victim's user agent. Second, the victim uses that session 1834 identifier to interact with the server, possibly imbuing the session 1835 identifier with the user's credentials or confidential information. 1836 Third, the attacker uses the session identifier to interact with 1837 server directly, possibly obtaining the user's authority or 1838 confidential information. 1840 8.5. Weak Confidentiality 1842 Cookies do not provide isolation by port. If a cookie is readable by 1843 a service running on one port, the cookie is also readable by a 1844 service running on another port of the same server. If a cookie is 1845 writable by a service on one port, the cookie is also writable by a 1846 service running on another port of the same server. For this reason, 1847 servers SHOULD NOT both run mutually distrusting services on 1848 different ports of the same host and use cookies to store security- 1849 sensitive information. 1851 Cookies do not provide isolation by scheme. Although most commonly 1852 used with the http and https schemes, the cookies for a given host 1853 might also be available to other schemes, such as ftp and gopher. 1854 Although this lack of isolation by scheme is most apparent in non- 1855 HTTP APIs that permit access to cookies (e.g., HTML's document.cookie 1856 API), the lack of isolation by scheme is actually present in 1857 requirements for processing cookies themselves (e.g., consider 1858 retrieving a URI with the gopher scheme via HTTP). 1860 Cookies do not always provide isolation by path. Although the 1861 network-level protocol does not send cookies stored for one path to 1862 another, some user agents expose cookies via non-HTTP APIs, such as 1863 HTML's document.cookie API. Because some of these user agents (e.g., 1864 web browsers) do not isolate resources received from different paths, 1865 a resource retrieved from one path might be able to access cookies 1866 stored for another path. 1868 8.6. Weak Integrity 1870 Cookies do not provide integrity guarantees for sibling domains (and 1871 their subdomains). For example, consider foo.example.com and 1872 bar.example.com. The foo.example.com server can set a cookie with a 1873 Domain attribute of "example.com" (possibly overwriting an existing 1874 "example.com" cookie set by bar.example.com), and the user agent will 1875 include that cookie in HTTP requests to bar.example.com. In the 1876 worst case, bar.example.com will be unable to distinguish this cookie 1877 from a cookie it set itself. The foo.example.com server might be 1878 able to leverage this ability to mount an attack against 1879 bar.example.com. 1881 Even though the Set-Cookie header supports the Path attribute, the 1882 Path attribute does not provide any integrity protection because the 1883 user agent will accept an arbitrary Path attribute in a Set-Cookie 1884 header. For example, an HTTP response to a request for 1885 http://example.com/foo/bar can set a cookie with a Path attribute of 1886 "/qux". Consequently, servers SHOULD NOT both run mutually 1887 distrusting services on different paths of the same host and use 1888 cookies to store security-sensitive information. 1890 An active network attacker can also inject cookies into the Cookie 1891 header sent to https://example.com/ by impersonating a response from 1892 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1893 server at example.com will be unable to distinguish these cookies 1894 from cookies that it set itself in an HTTPS response. An active 1895 network attacker might be able to leverage this ability to mount an 1896 attack against example.com even if example.com uses HTTPS 1897 exclusively. 1899 Servers can partially mitigate these attacks by encrypting and 1900 signing the contents of their cookies. However, using cryptography 1901 does not mitigate the issue completely because an attacker can replay 1902 a cookie he or she received from the authentic example.com server in 1903 the user's session, with unpredictable results. 1905 Finally, an attacker might be able to force the user agent to delete 1906 cookies by storing a large number of cookies. Once the user agent 1907 reaches its storage limit, the user agent will be forced to evict 1908 some cookies. Servers SHOULD NOT rely upon user agents retaining 1909 cookies. 1911 8.7. Reliance on DNS 1913 Cookies rely upon the Domain Name System (DNS) for security. If the 1914 DNS is partially or fully compromised, the cookie protocol might fail 1915 to provide the security properties required by applications. 1917 8.8. SameSite Cookies 1919 8.8.1. Defense in depth 1921 "SameSite" cookies offer a robust defense against CSRF attack when 1922 deployed in strict mode, and when supported by the client. It is, 1923 however, prudent to ensure that this designation is not the extent of 1924 a site's defense against CSRF, as same-site navigations and 1925 submissions can certainly be executed in conjunction with other 1926 attack vectors such as cross-site scripting. 1928 Developers are strongly encouraged to deploy the usual server-side 1929 defenses (CSRF tokens, ensuring that "safe" HTTP methods are 1930 idempotent, etc) to mitigate the risk more fully. 1932 Additionally, client-side techniques such as those described in 1933 [app-isolation] may also prove effective against CSRF, and are 1934 certainly worth exploring in combination with "SameSite" cookies. 1936 8.8.2. Top-level Navigations 1938 Setting the "SameSite" attribute in "strict" mode provides robust 1939 defense in depth against CSRF attacks, but has the potential to 1940 confuse users unless sites' developers carefully ensure that their 1941 cookie-based session management systems deal reasonably well with 1942 top-level navigations. 1944 Consider the scenario in which a user reads their email at MegaCorp 1945 Inc's webmail provider "https://example.com/". They might expect 1946 that clicking on an emailed link to "https://projects.com/secret/ 1947 project" would show them the secret project that they're authorized 1948 to see, but if "projects.com" has marked their session cookies as 1949 "SameSite", then this cross-site navigation won't send them along 1950 with the request. "projects.com" will render a 404 error to avoid 1951 leaking secret information, and the user will be quite confused. 1953 Developers can avoid this confusion by adopting a session management 1954 system that relies on not one, but two cookies: one conceptually 1955 granting "read" access, another granting "write" access. The latter 1956 could be marked as "SameSite", and its absence would prompt a 1957 reauthentication step before executing any non-idempotent action. 1958 The former could drop the "SameSite" attribute entirely, or choose 1959 the "Lax" version of enforcement, in order to allow users access to 1960 data via top-level navigation. 1962 8.8.3. Mashups and Widgets 1964 The "SameSite" attribute is inappropriate for some important use- 1965 cases. In particular, note that content intended for embedding in a 1966 cross-site contexts (social networking widgets or commenting 1967 services, for instance) will not have access to same-site cookies. 1968 Cookies may be required for requests triggered in these cross-site 1969 contexts in order to provide seamless functionality that relies on a 1970 user's state. 1972 Likewise, some forms of Single-Sign-On might require cookie-based 1973 authentication in a cross-site context; these mechanisms will not 1974 function as intended with same-site cookies. 1976 8.8.4. Server-controlled 1978 SameSite cookies in and of themselves don't do anything to address 1979 the general privacy concerns outlined in Section 7.1 of [RFC6265]. 1980 The "SameSite" attribute is set by the server, and serves to mitigate 1981 the risk of certain kinds of attacks that the server is worried 1982 about. The user is not involved in this decision. Moreover, a 1983 number of side-channels exist which could allow a server to link 1984 distinct requests even in the absence of cookies. Connection and/or 1985 socket pooling, Token Binding, and Channel ID all offer explicit 1986 methods of identification that servers could take advantage of. 1988 9. IANA Considerations 1990 The permanent message header field registry (see [RFC3864]) needs to 1991 be updated with the following registrations. 1993 9.1. Cookie 1995 Header field name: Cookie 1997 Applicable protocol: http 1999 Status: standard 2001 Author/Change controller: IETF 2003 Specification document: this specification (Section 5.5) 2005 9.2. Set-Cookie 2007 Header field name: Set-Cookie 2009 Applicable protocol: http 2011 Status: standard 2013 Author/Change controller: IETF 2015 Specification document: this specification (Section 5.3) 2017 10. References 2019 10.1. Normative References 2021 [FETCH] van Kesteren, A., "Fetch", n.d., 2022 . 2024 [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, 2025 P., and D. Denicola, "HTML", n.d., 2026 . 2028 [PSL] "Public Suffix List", n.d., . 2031 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2032 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2033 . 2035 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 2036 Application and Support", STD 3, RFC 1123, 2037 DOI 10.17487/RFC1123, October 1989, 2038 . 2040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2041 Requirement Levels", BCP 14, RFC 2119, 2042 DOI 10.17487/RFC2119, March 1997, 2043 . 2045 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2046 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2047 Transfer Protocol -- HTTP/1.1", RFC 2616, 2048 DOI 10.17487/RFC2616, June 1999, 2049 . 2051 [RFC3490] Costello, A., "Internationalizing Domain Names in 2052 Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, 2053 March 2003, . 2055 See Section 6.3 for an explanation why the normative 2056 reference to an obsoleted specification is needed. 2058 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 2059 Application Protocol Collation Registry", RFC 4790, 2060 DOI 10.17487/RFC4790, March 2007, 2061 . 2063 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2064 Specifications: ABNF", STD 68, RFC 5234, 2065 DOI 10.17487/RFC5234, January 2008, 2066 . 2068 [RFC5890] Klensin, J., "Internationalized Domain Names for 2069 Applications (IDNA): Definitions and Document Framework", 2070 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2071 . 2073 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2074 DOI 10.17487/RFC6454, December 2011, 2075 . 2077 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2078 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2079 DOI 10.17487/RFC7231, June 2014, 2080 . 2082 [SERVICE-WORKERS] 2083 Russell, A., Song, J., and J. Archibald, "Service 2084 Workers", n.d., . 2086 [USASCII] American National Standards Institute, "Coded Character 2087 Set -- 7-bit American Standard Code for Information 2088 Interchange", ANSI X3.4, 1986. 2090 10.2. Informative References 2092 [Aggarwal2010] 2093 Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, 2094 "An Analysis of Private Browsing Modes in Modern 2095 Browsers", 2010, 2096 . 2099 [app-isolation] 2100 Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson, 2101 "App Isolation - Get the Security of Multiple Browsers 2102 with Just One", 2011, 2103 . 2106 [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses 2107 for Cross-Site Request Forgery", 2108 DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, 2109 ACM CCS '08: Proceedings of the 15th ACM conference on 2110 Computer and communications security (pages 75-88), 2111 October 2008, 2112 . 2114 [I-D.ietf-httpbis-cookie-alone] 2115 West, M., "Deprecate modification of 'secure' cookies from 2116 non-secure origins", draft-ietf-httpbis-cookie-alone-01 2117 (work in progress), September 2016. 2119 [I-D.ietf-httpbis-cookie-prefixes] 2120 West, M., "Cookie Prefixes", draft-ietf-httpbis-cookie- 2121 prefixes-00 (work in progress), February 2016. 2123 [I-D.ietf-httpbis-cookie-same-site] 2124 West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf- 2125 httpbis-cookie-same-site-00 (work in progress), June 2016. 2127 [prerendering] 2128 Bentzel, C., "Chrome Prerendering", n.d., 2129 . 2132 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2133 DOI 10.17487/RFC2818, May 2000, 2134 . 2136 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2137 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2138 2003, . 2140 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2141 Procedures for Message Header Fields", BCP 90, RFC 3864, 2142 DOI 10.17487/RFC3864, September 2004, 2143 . 2145 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2146 Resource Identifier (URI): Generic Syntax", STD 66, 2147 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2148 . 2150 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2151 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2152 . 2154 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 2155 Internationalized Domain Names in Applications (IDNA) 2156 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 2157 . 2159 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2160 DOI 10.17487/RFC6265, April 2011, 2161 . 2163 [RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame- 2164 Options", RFC 7034, DOI 10.17487/RFC7034, October 2013, 2165 . 2167 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 2168 Processing", UNICODE Unicode Technical Standards # 46, 2169 June 2016, . 2171 Appendix A. Changes 2173 A.1. draft-ietf-httpbis-rfc6265bis-00 2175 o Port [RFC6265] to Markdown. No (intentional) normative changes. 2177 A.2. draft-ietf-httpbis-rfc6265bis-01 2179 o Fixes to formatting caused by mistakes in the initial port to 2180 Markdown: 2182 * https://github.com/httpwg/http-extensions/issues/243 2184 * https://github.com/httpwg/http-extensions/issues/246 2186 o Addresses errata 3444 by updating the "path-value" and "extension- 2187 av" grammar, errata 4148 by updating the "day-of-month", "year", 2188 and "time" grammar, and errata 3663 by adding the requested note. 2189 https://www.rfc-editor.org/errata_search.php?rfc=6265 2191 o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations 2192 section: https://github.com/httpwg/http-extensions/issues/247 2194 o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], 2195 removing the ability for a non-secure origin to set cookies with a 2196 'secure' flag, and to overwrite cookies whose 'secure' flag is 2197 true. 2199 o Merged the recommendations from 2200 [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and 2201 "__Host-" cookie name prefix processing instructions. 2203 A.3. draft-ietf-httpbis-rfc6265bis-02 2205 o Merged the recommendations from 2206 [I-D.ietf-httpbis-cookie-same-site], adding support for the 2207 "SameSite" attribute. 2209 o Closed a number of editorial bugs: 2211 * Clarified address bar behavior for SameSite cookies: 2212 https://github.com/httpwg/http-extensions/issues/201 2214 * Added the word "Cookies" to the document's name: 2215 https://github.com/httpwg/http-extensions/issues/204 2217 * Clarified that the "__Host-" prefix requires an explicit "Path" 2218 attribute: https://github.com/httpwg/http-extensions/issues/222 2220 * Expanded the options for dealing with third-party cookies to 2221 include a brief mention of partitioning based on first-party: 2222 https://github.com/httpwg/http-extensions/issues/248 2224 * Noted that double-quotes in cookie values are part of the 2225 value, and are not stripped: https://github.com/httpwg/http- 2226 extensions/issues/295 2228 * Fixed the "site for cookies" algorithm to return something that 2229 makes sense: https://github.com/httpwg/http-extensions/ 2230 issues/302 2232 Appendix B. Acknowledgements 2234 This document is a minor update of RFC 6265, adding small features, 2235 and aligning the specification with the reality of today's 2236 deployments. Here, we're standing upon the shoulders of giants. 2238 Authors' Addresses 2240 Adam Barth 2241 Google, Inc 2243 URI: https://www.adambarth.com/ 2245 Mike West 2246 Google, Inc 2248 Email: mkwst@google.com 2249 URI: https://mikewest.org/