draft-ietf-httpbis-rfc6265bis-01.txt   draft-ietf-httpbis-rfc6265bis-02.txt 
HTTP Working Group A. Barth HTTP Working Group A. Barth
Internet-Draft M. West Internet-Draft M. West
Obsoletes: 6265 (if approved) Google, Inc Obsoletes: 6265 (if approved) Google, Inc
Intended status: Standards Track April 25, 2017 Intended status: Standards Track August 7, 2017
Expires: October 27, 2017 Expires: February 8, 2018
HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-01 draft-ietf-httpbis-rfc6265bis-02
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 2965. on the Internet. This document obsoletes RFC 6265.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ . https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ; Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/6265bis . https://github.com/httpwg/http-extensions/labels/6265bis .
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2017. This Internet-Draft will expire on February 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 13 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 15 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 17 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 18 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 18 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21 5.2.1. Document-based requests . . . . . . . . . . . . . . . 20
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 21
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . 22 5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . 22 5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . 23 5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 25
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 23 5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23 5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 26
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 27 5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27
6. Implementation Considerations . . . . . . . . . . . . . . . . 29 5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27
6.2. Application Programming Interfaces . . . . . . . . . . . 29 5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 30 5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 6. Implementation Considerations . . . . . . . . . . . . . . . . 35
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 31 6.2. Application Programming Interfaces . . . . . . . . . . . 35
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 31 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 33 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 34 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 37
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 35 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 39
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 36 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . 37 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 41
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 39 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 42
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 39 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 47
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 47
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 47
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 4, line 44 skipping to change at page 5, line 5
they are actually used on the Internet. In particular, this document they are actually used on the Internet. In particular, this document
does not create new syntax or semantics beyond those in use today. does not create new syntax or semantics beyond those in use today.
The recommendations for cookie generation provided in Section 4 The recommendations for cookie generation provided in Section 4
represent a preferred subset of current server behavior, and even the represent a preferred subset of current server behavior, and even the
more liberal cookie processing algorithm provided in Section 5 does more liberal cookie processing algorithm provided in Section 5 does
not recommend all of the syntactic and semantic variations in use not recommend all of the syntactic and semantic variations in use
today. Where some existing software differs from the recommended today. Where some existing software differs from the recommended
protocol in significant ways, the document contains a note explaining protocol in significant ways, the document contains a note explaining
the difference. the difference.
Prior to this document, there were at least three descriptions of This document obsoletes [RFC6265].
cookies: the so-called "Netscape cookie specification" [Netscape],
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
documents describe how the Cookie and Set-Cookie headers are actually
used on the Internet (see [Kri2001] for historical context). In
relation to previous IETF specifications of HTTP state management
mechanisms, this document requests the following actions:
1. Change the status of [RFC2109] to Historic (it has already been
obsoleted by [RFC2965]).
2. Change the status of [RFC2965] to Historic.
3. Indicate that [RFC2965] has been obsoleted by this document.
In particular, in moving RFC 2965 to Historic and obsoleting it, this
document deprecates the use of the Cookie2 and Set-Cookie2 header
fields.
2. Conventions 2. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
skipping to change at page 6, line 31 skipping to change at page 6, line 24
sent the corresponding HTTP request). sent the corresponding HTTP request).
The term request-uri is defined in Section 5.1.2 of [RFC2616]. The term request-uri is defined in Section 5.1.2 of [RFC2616].
Two sequences of octets are said to case-insensitively match each Two sequences of octets are said to case-insensitively match each
other if and only if they are equivalent under the i;ascii-casemap other if and only if they are equivalent under the i;ascii-casemap
collation defined in [RFC4790]. collation defined in [RFC4790].
The term string means a sequence of non-NUL octets. The term string means a sequence of non-NUL octets.
The terms "active document", "ancestor browsing context", "browsing
context", "dedicated worker", "Document", "WorkerGlobalScope",
"sandboxed origin browsing context flag", "parent browsing context",
"shared worker", "the worker's Documents", "nested browsing context",
and "top-level browsing context" are defined in [HTML].
"Service Workers" are defined in the Service Workers specification
[SERVICE-WORKERS].
The term "origin", the mechanism of deriving an origin from a URI,
and the "the same" matching algorithm for origins are defined in
[RFC6454].
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
defined in Section 4.2.1 of [RFC7231].
The term "public suffix" is defined in a note in Section 5.3 of
[RFC6265] as "a domain that is controlled by a public registry", and
are also know as "effective top-level domains" (eTLDs). For example,
"example.com"'s public suffix is "com". User agents SHOULD use an
up-to-date public suffix list, such as the one maintained by Mozilla
at [PSL].
An origin's "registered domain" is the origin's host's public suffix
plus the label to its left. That is, for "https://www.example.com",
the public suffix is "com", and the registered domain is
"example.com". This concept is defined more rigorously in [PSL], and
is also know as "effective top-level domain plus one" (eTLD+1).
The term "request", as well as a request's "client", "current url",
"method", and "target browsing context", are defined in [FETCH].
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header in an To store state, the origin server includes a Set-Cookie header in an
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
contains cookies the user agent received in previous Set-Cookie contains cookies the user agent received in previous Set-Cookie
skipping to change at page 9, line 31 skipping to change at page 10, line 18
cookie-name = token cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs, ; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon, ; whitespace DQUOTE, comma, semicolon,
; and backslash ; and backslash
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
extension-av samesite-av / extension-av
expires-av = "Expires=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = sane-cookie-date =
<rfc1123-date, defined in [RFC2616], Section 3.3.1> <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av ; In practice, both expires-av and max-age-av
; are limited to dates representable by the ; are limited to dates representable by the
; user agent. ; user agent.
non-zero-digit = %x31-39 non-zero-digit = %x31-39
; digits 1 through 9 ; digits 1 through 9
domain-av = "Domain=" domain-value domain-av = "Domain=" domain-value
domain-value = <subdomain> domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as ; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1 ; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value path-av = "Path=" path-value
path-value = *av-octet path-value = *av-octet
secure-av = "Secure" secure-av = "Secure"
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
samesite-av = "SameSite=" samesite-value
samesite-value = "Strict" / "Lax"
extension-av = *av-octet extension-av = *av-octet
av-octet = %x20-3A / %x3C-7E av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";" ; any CHAR except CTLs or ";"
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base64 [RFC4648]. example, using Base64 [RFC4648].
Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
characters. Note that in this case, the initial and trailing DQUOTE
characters are not stripped. They are part of the cookie-value, and
will be included in Cookie headers sent to the server.
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
servers SHOULD NOT produce two attributes with the same name in the servers SHOULD NOT produce two attributes with the same name in the
same set-cookie-string. (See Section 5.3 for how user agents handle same set-cookie-string. (See Section 5.4 for how user agents handle
this case.) this case.)
Servers SHOULD NOT include more than one Set-Cookie header field in Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for the same response with the same cookie-name. (See Section 5.3 for
how user agents handle this case.) how user agents handle this case.)
If a server sends multiple responses containing Set-Cookie headers If a server sends multiple responses containing Set-Cookie headers
concurrently to the user agent (e.g., when communicating with the concurrently to the user agent (e.g., when communicating with the
user agent over multiple sockets), these responses create a "race user agent over multiple sockets), these responses create a "race
condition" that can lead to unpredictable behavior. condition" that can lead to unpredictable behavior.
NOTE: Some existing user agents differ in their interpretation of NOTE: Some existing user agents differ in their interpretation of
two-digit years. To avoid compatibility issues, servers SHOULD use two-digit years. To avoid compatibility issues, servers SHOULD use
the rfc1123-date format, which requires a four-digit year. the rfc1123-date format, which requires a four-digit year.
skipping to change at page 12, line 21 skipping to change at page 13, line 17
The user agent will reject cookies unless the Domain attribute The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a server. For example, the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com". Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes". For example, Domain attributes that correspond to "public suffixes". For example,
some user agents will reject Domain attributes of "com" or "co.uk". some user agents will reject Domain attributes of "com" or "co.uk".
(See Section 5.3 for more information.) (See Section 5.4 for more information.)
4.1.2.4. The Path Attribute 4.1.2.4. The Path Attribute
The scope of each cookie is limited to a set of paths, controlled by The scope of each cookie is limited to a set of paths, controlled by
the Path attribute. If the server omits the Path attribute, the user the Path attribute. If the server omits the Path attribute, the user
agent will use the "directory" of the request-uri's path component as agent will use the "directory" of the request-uri's path component as
the default value. (See Section 5.1.4 for more details.) the default value. (See Section 5.1.4 for more details.)
The user agent will include the cookie in an HTTP request only if the The user agent will include the cookie in an HTTP request only if the
path portion of the request-uri matches (or is a subdirectory of) the path portion of the request-uri matches (or is a subdirectory of) the
skipping to change at page 13, line 16 skipping to change at page 14, line 16
The HttpOnly attribute limits the scope of the cookie to HTTP The HttpOnly attribute limits the scope of the cookie to HTTP
requests. In particular, the attribute instructs the user agent to requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to cookies via "non-HTTP" APIs omit the cookie when providing access to cookies via "non-HTTP" APIs
(such as a web browser API that exposes cookies to scripts). (such as a web browser API that exposes cookies to scripts).
Note that the HttpOnly attribute is independent of the Secure Note that the HttpOnly attribute is independent of the Secure
attribute: a cookie can have both the HttpOnly and the Secure attribute: a cookie can have both the HttpOnly and the Secure
attribute. attribute.
4.1.2.7. The SameSite Attribute
The "SameSite" attribute limits the scope of the cookie such that it
will only be attached to requests if those requests are same-site, as
defined by the algorithm in Section 5.2. For example, requests for
"https://example.com/sekrit-image" will attach same-site cookies if
and only if initiated from a context whose "site for cookies" is
"example.com".
If the "SameSite" attribute's value is "Strict", the cookie will only
be sent along with "same-site" requests. If the value is "Lax", the
cookie will be sent with same-site requests, and with "cross-site"
top-level navigations, as described in Section 5.3.7.1. If the
"SameSite" attribute's value is neither of these, the cookie will be
ignored.
4.1.3. Cookie Name Prefixes 4.1.3. Cookie Name Prefixes
Section 8.5 and 8.6 of this document spell out some of the drawbacks Section 8.5 and Section 8.6 of this document spell out some of the
of cookies' historical implementation. In particular, it is drawbacks of cookies' historical implementation. In particular, it
impossible for a server to have confidence that a given cookie was is impossible for a server to have confidence that a given cookie was
set with a particular set of attributes. In order to provide such set with a particular set of attributes. In order to provide such
confidence in a backwards-compatible way, two common sets of confidence in a backwards-compatible way, two common sets of
requirements can be inferred from the first few characters of the requirements can be inferred from the first few characters of the
cookie's name. cookie's name.
The normative requirements for the prefixes described below are The normative requirements for the prefixes described below are
detailed in the storage model algorithm defined in Section 5.3. detailed in the storage model algorithm defined in Section 5.4.
4.1.3.1. The "__Secure-" Prefix 4.1.3.1. The "__Secure-" Prefix
If a cookie's name begins with a case-sensitive match for the string If a cookie's name begins with a case-sensitive match for the string
"__Secure-", then the cookie will have been set with a "Secure" "__Secure-", then the cookie will have been set with a "Secure"
attribute. attribute.
For example, the following "Set-Cookie" header would be rejected by a For example, the following "Set-Cookie" header would be rejected by a
conformant user agent, as it does not have a "Secure" attribute. conformant user agent, as it does not have a "Secure" attribute.
skipping to change at page 19, line 12 skipping to change at page 20, line 16
of the path component, and hence two equivalent paths can have of the path component, and hence two equivalent paths can have
different cookies. different cookies.
o The cookie-path is a prefix of the request-path, and the last o The cookie-path is a prefix of the request-path, and the last
character of the cookie-path is %x2F ("/"). character of the cookie-path is %x2F ("/").
o The cookie-path is a prefix of the request-path, and the first o The cookie-path is a prefix of the request-path, and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. The Set-Cookie Header 5.2. "Same-site" and "cross-site" Requests
A request is "same-site" if its target's URI's origin's registered
domain is an exact match for the request's client's "site for
cookies", or if the request has no client. The request is otherwise
"cross-site".
For a given request ("request"), the following algorithm returns
"same-site" or "cross-site":
1. If "request"'s client is "null", return "same-site".
Note that this is the case for navigation triggered by the user
directly (e.g. by typing directly into a user agent's address
bar).
2. Let "site" be "request"'s client's "site for cookies" (as defined
in the following sections).
3. Let "target" be the registered domain of "request"'s current url.
4. If "site" is an exact match for "target", return "same-site".
5. Return "cross-site".
The request's client's "site for cookies" is calculated depending
upon its client's type, as described in the following subsections:
5.2.1. Document-based requests
The URI displayed in a user agent's address bar is the only security
context directly exposed to users, and therefore the only signal
users can reasonably rely upon to determine whether or not they trust
a particular website. The registered domain of that URI's origin
represents the context in which a user most likely believes
themselves to be interacting. We'll label this domain the "top-level
site".
For a document displayed in a top-level browsing context, we can stop
here: the document's "site for cookies" is the top-level site.
For documents which are displayed in nested browsing contexts, we
need to audit the origins of each of a document's ancestor browsing
contexts' active documents in order to account for the "multiple-
nested scenarios" described in Section 4 of [RFC7034]. These
document's "site for cookies" is the top-level site if and only if
the document and each of its ancestor documents' origins have the
same registered domain as the top-level site. Otherwise its "site
for cookies" is the empty string.
Given a Document ("document"), the following algorithm returns its
"site for cookies" (either a registered domain, or the empty string):
1. Let "top-document" be the active document in "document"'s
browsing context's top-level browsing context.
2. Let "top-origin" be the origin of "top-document"'s URI if "top-
document"'s sandboxed origin browsing context flag is set, and
"top-document"'s origin otherwise.
3. Let "documents" be a list containing "document" and each of
"document"'s ancestor browsing contexts' active documents.
4. For each "item" in "documents":
1. Let "origin" be the origin of "item"'s URI if "item"'s
sandboxed origin browsing context flag is set, and "item"'s
origin otherwise.
2. If "origin"'s host's registered domain is not an exact match
for "top-origin"'s host's registered domain, return the empty
string.
5. Return "top-origin"'s host's registered domain.
5.2.2. Worker-based requests
Worker-driven requests aren't as clear-cut as document-driven
requests, as there isn't a clear link between a top-level browsing
context and a worker. This is especially true for Service Workers
[SERVICE-WORKERS], which may execute code in the background, without
any document visible at all.
Note: The descriptions below assume that workers must be same-origin
with the documents that instantiate them. If this invariant changes,
we'll need to take the worker's script's URI into account when
determining their status.
5.2.2.1. Dedicated and Shared Workers
Dedicated workers are simple, as each dedicated worker is bound to
one and only one document. Requests generated from a dedicated
worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
their "site for cookies" as that document's "site for cookies".
Shared workers may be bound to multiple documents at once. As it is
quite possible for those documents to have distinct "site for cookie"
values, the worker's "site for cookies" will be the empty string in
cases where the values diverge, and the shared value in cases where
the values agree.
Given a WorkerGlobalScope ("worker"), the following algorithm returns
its "site for cookies" (either a registered domain, or the empty
string):
1. Let "site" be "worker"'s origin's host's registered domain.
2. For each "document" in "worker"'s Documents:
1. Let "document-site" be "document"'s "site for cookies" (as
defined in Section 5.2.1).
2. If "document-site" is not an exact match for "site", return
the empty string.
3. Return "site".
5.2.2.2. Service Workers
Service Workers are more complicated, as they act as a completely
separate execution context with only tangential relationship to the
Document which registered them.
Requests which simply pass through a service worker will be handled
as described above: the request's client will be the Document or
Worker which initiated the request, and its "site for cookies" will
be those defined in Section 5.2.1 and Section 5.2.2.1
Requests which are initiated by the Service Worker itself (via a
direct call to "fetch()", for instance), on the other hand, will have
a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
will be the registered domain of the Service Worker's URI.
Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
returns its "site for cookies" (either a registered domain, or the
empty string):
1. Return "worker"'s origin's host's registered domain.
5.3. The Set-Cookie Header
When a user agent receives a Set-Cookie header field in an HTTP When a user agent receives a Set-Cookie header field in an HTTP
response, the user agent MAY ignore the Set-Cookie header field in response, the user agent MAY ignore the Set-Cookie header field in
its entirety. For example, the user agent might wish to block its entirety. For example, the user agent might wish to block
responses to "third-party" requests from setting cookies (see responses to "third-party" requests from setting cookies (see
Section 7.1). Section 7.1).
If the user agent does not ignore the Set-Cookie header field in its If the user agent does not ignore the Set-Cookie header field in its
entirety, the user agent MUST parse the field-value of the Set-Cookie entirety, the user agent MUST parse the field-value of the Set-Cookie
header field as a set-cookie-string (defined below). header field as a set-cookie-string (defined below).
skipping to change at page 21, line 14 skipping to change at page 25, line 14
6. Process the attribute-name and attribute-value according to the 6. Process the attribute-name and attribute-value according to the
requirements in the following subsections. (Notice that requirements in the following subsections. (Notice that
attributes with unrecognized attribute-names are ignored.) attributes with unrecognized attribute-names are ignored.)
7. Return to Step 1 of this algorithm. 7. Return to Step 1 of this algorithm.
When the user agent finishes parsing the set-cookie-string, the user When the user agent finishes parsing the set-cookie-string, the user
agent is said to "receive a cookie" from the request-uri with name agent is said to "receive a cookie" from the request-uri with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list. (See Section 5.3 for additional requirements triggered by list. (See Section 5.4 for additional requirements triggered by
receiving a cookie.) receiving a cookie.)
5.2.1. The Expires Attribute 5.3.1. The Expires Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"Expires", the user agent MUST process the cookie-av as follows. "Expires", the user agent MUST process the cookie-av as follows.
1. Let the expiry-time be the result of parsing the attribute-value 1. Let the expiry-time be the result of parsing the attribute-value
as cookie-date (see Section 5.1.1). as cookie-date (see Section 5.1.1).
2. If the attribute-value failed to parse as a cookie date, ignore 2. If the attribute-value failed to parse as a cookie date, ignore
the cookie-av. the cookie-av.
skipping to change at page 21, line 39 skipping to change at page 25, line 39
represent, the user agent MAY replace the expiry-time with the represent, the user agent MAY replace the expiry-time with the
last representable date. last representable date.
4. If the expiry-time is earlier than the earliest date the user 4. If the expiry-time is earlier than the earliest date the user
agent can represent, the user agent MAY replace the expiry-time agent can represent, the user agent MAY replace the expiry-time
with the earliest representable date. with the earliest representable date.
5. Append an attribute to the cookie-attribute-list with an 5. Append an attribute to the cookie-attribute-list with an
attribute-name of Expires and an attribute-value of expiry-time. attribute-name of Expires and an attribute-value of expiry-time.
5.2.2. The Max-Age Attribute 5.3.2. The Max-Age Attribute
If the attribute-name case-insensitively matches the string "Max- If the attribute-name case-insensitively matches the string "Max-
Age", the user agent MUST process the cookie-av as follows. Age", the user agent MUST process the cookie-av as follows.
1. If the first character of the attribute-value is not a DIGIT or a 1. If the first character of the attribute-value is not a DIGIT or a
"-" character, ignore the cookie-av. "-" character, ignore the cookie-av.
2. If the remainder of attribute-value contains a non-DIGIT 2. If the remainder of attribute-value contains a non-DIGIT
character, ignore the cookie-av. character, ignore the cookie-av.
3. Let delta-seconds be the attribute-value converted to an integer. 3. Let delta-seconds be the attribute-value converted to an integer.
4. If delta-seconds is less than or equal to zero (0), let expiry- 4. If delta-seconds is less than or equal to zero (0), let expiry-
time be the earliest representable date and time. Otherwise, let time be the earliest representable date and time. Otherwise, let
the expiry-time be the current date and time plus delta-seconds the expiry-time be the current date and time plus delta-seconds
seconds. seconds.
5. Append an attribute to the cookie-attribute-list with an 5. Append an attribute to the cookie-attribute-list with an
attribute-name of Max-Age and an attribute-value of expiry-time. attribute-name of Max-Age and an attribute-value of expiry-time.
5.2.3. The Domain Attribute 5.3.3. The Domain Attribute
If the attribute-name case-insensitively matches the string "Domain", If the attribute-name case-insensitively matches the string "Domain",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
1. If the attribute-value is empty, the behavior is undefined. 1. If the attribute-value is empty, the behavior is undefined.
However, the user agent SHOULD ignore the cookie-av entirely. However, the user agent SHOULD ignore the cookie-av entirely.
2. If the first character of the attribute-value string is %x2E 2. If the first character of the attribute-value string is %x2E
("."): ("."):
skipping to change at page 22, line 36 skipping to change at page 26, line 36
Otherwise: Otherwise:
1. Let cookie-domain be the entire attribute-value. 1. Let cookie-domain be the entire attribute-value.
3. Convert the cookie-domain to lower case. 3. Convert the cookie-domain to lower case.
4. Append an attribute to the cookie-attribute-list with an 4. Append an attribute to the cookie-attribute-list with an
attribute-name of Domain and an attribute-value of cookie-domain. attribute-name of Domain and an attribute-value of cookie-domain.
5.2.4. The Path Attribute 5.3.4. The Path Attribute
If the attribute-name case-insensitively matches the string "Path", If the attribute-name case-insensitively matches the string "Path",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
1. If the attribute-value is empty or if the first character of the 1. If the attribute-value is empty or if the first character of the
attribute-value is not %x2F ("/"): attribute-value is not %x2F ("/"):
1. Let cookie-path be the default-path. 1. Let cookie-path be the default-path.
Otherwise: Otherwise:
1. Let cookie-path be the attribute-value. 1. Let cookie-path be the attribute-value.
2. Append an attribute to the cookie-attribute-list with an 2. Append an attribute to the cookie-attribute-list with an
attribute-name of Path and an attribute-value of cookie-path. attribute-name of Path and an attribute-value of cookie-path.
5.2.5. The Secure Attribute 5.3.5. The Secure Attribute
If the attribute-name case-insensitively matches the string "Secure", If the attribute-name case-insensitively matches the string "Secure",
the user agent MUST append an attribute to the cookie-attribute-list the user agent MUST append an attribute to the cookie-attribute-list
with an attribute-name of Secure and an empty attribute-value. with an attribute-name of Secure and an empty attribute-value.
5.2.6. The HttpOnly Attribute 5.3.6. The HttpOnly Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"HttpOnly", the user agent MUST append an attribute to the cookie- "HttpOnly", the user agent MUST append an attribute to the cookie-
attribute-list with an attribute-name of HttpOnly and an empty attribute-list with an attribute-name of HttpOnly and an empty
attribute-value. attribute-value.
5.3. Storage Model 5.3.7. The SameSite Attribute
If the attribute-name case-insensitively matches the string
"SameSite", the user agent MUST process the cookie-av as follows:
1. If cookie-av's attribute-value is not a case-insensitive match
for "Strict" or "Lax", ignore the "cookie-av".
2. Let "enforcement" be "Lax" if cookie-av's attribute-value is a
case-insensitive match for "Lax", and "Strict" otherwise.
3. Append an attribute to the cookie-attribute-list with an
attribute-name of "SameSite" and an attribute-value of
"enforcement".
5.3.7.1. "Strict" and "Lax" enforcement
Same-site cookies in "Strict" enforcement mode will not be sent along
with top-level navigations which are triggered from a cross-site
document context. As discussed in Section 8.8.2, this might or might
not be compatible with existing session management systems. In the
interests of providing a drop-in mechanism that mitigates the risk of
CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
enforcement mode that carves out an exception which sends same-site
cookies along with cross-site requests if and only if they are top-
level navigations which use a "safe" (in the [RFC7231] sense) HTTP
method.
Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but does not
offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as
described in section 2.1), which is only a speedbump along the
road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user
detection.
When possible, developers should use a session management mechanism
such as that described in Section 8.8.2 to mitigate the risk of CSRF
more completely.
5.4. Storage Model
The user agent stores the following fields about each cookie: name, The user agent stores the following fields about each cookie: name,
value, expiry-time, domain, path, creation-time, last-access-time, value, expiry-time, domain, path, creation-time, last-access-time,
persistent-flag, host-only-flag, secure-only-flag, and http-only- persistent-flag, host-only-flag, secure-only-flag, http-only-flag,
flag. and same-site-flag.
When the user agent "receives a cookie" from a request-uri with name When the user agent "receives a cookie" from a request-uri with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list, the user agent MUST process the cookie as follows: list, the user agent MUST process the cookie as follows:
1. A user agent MAY ignore a received cookie in its entirety. For 1. A user agent MAY ignore a received cookie in its entirety. For
example, the user agent might wish to block receiving cookies example, the user agent might wish to block receiving cookies
from "third-party" responses or the user agent might not wish to from "third-party" responses or the user agent might not wish to
store cookies that exceed some size. store cookies that exceed some size.
skipping to change at page 24, line 17 skipping to change at page 29, line 17
name of "Expires". name of "Expires".
Otherwise: Otherwise:
1. Set the cookie's persistent-flag to false. 1. Set the cookie's persistent-flag to false.
2. Set the cookie's expiry-time to the latest representable 2. Set the cookie's expiry-time to the latest representable
date. date.
4. If the cookie-attribute-list contains an attribute with an 4. If the cookie-attribute-list contains an attribute with an
attribute-name iof "Domain": attribute-name of "Domain":
1. Let the domain-attribute be the attribute-value of the last 1. Let the domain-attribute be the attribute-value of the last
attribute in the cookie-attribute-list with an attribute- attribute in the cookie-attribute-list with an attribute-
name of "Domain". name of "Domain".
Otherwise: Otherwise:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
5. If the user agent is configured to reject "public suffixes" and 5. If the user agent is configured to reject "public suffixes" and
skipping to change at page 26, line 19 skipping to change at page 31, line 19
of the existing cookie. of the existing cookie.
Note: The path comparison is not symmetric, ensuring only that a Note: The path comparison is not symmetric, ensuring only that a
newly-created, non-secure cookie does not overlay an existing newly-created, non-secure cookie does not overlay an existing
secure cookie, providing some mitigation against cookie-fixing secure cookie, providing some mitigation against cookie-fixing
attacks. That is, given an existing secure cookie named 'a' attacks. That is, given an existing secure cookie named 'a'
with a path of '/login', a non-secure cookie named 'a' could be with a path of '/login', a non-secure cookie named 'a' could be
set for a path of '/' or '/foo', but not for a path of '/login' set for a path of '/' or '/foo', but not for a path of '/login'
or '/login/en'. or '/login/en'.
13. If the cookie-name begins with a case-sensitive match for the 13. If the cookie-attribute-list contains an attribute with an
attribute-name of "SameSite", set the cookie's same-site-flag to
attribute-value (i.e. either "Strict" or "Lax"). Otherwise, set
the cookie's same-site-flag to "None".
14. If the cookie's "same-site-flag" is not "None", and the cookie
is being set from a context whose "site for cookies" is not an
exact match for request-uri's host's registered domain, then
abort these steps and ignore the newly created cookie entirely.
15. If the cookie-name begins with a case-sensitive match for the
string "__Secure-", abort these steps and ignore the cookie string "__Secure-", abort these steps and ignore the cookie
entirely unless the cookie's secure-only-flag is true. entirely unless the cookie's secure-only-flag is true.
14. If the cookie-name begins with a case-sensitive match for the 16. If the cookie-name begins with a case-sensitive match for the
string "__Host-", abort these steps and ignore the cookie string "__Host-", abort these steps and ignore the cookie
entirely unless the cookie meets all the following criteria: entirely unless the cookie meets all the following criteria:
1. The cookie's secure-only-flag is true. 1. The cookie's secure-only-flag is true.
2. The cookie's host-only-flag is true. 2. The cookie's host-only-flag is true.
3. The cookie's path is "/". 3. The cookie-attribute-list contains an attribute with an
attribute-name of "Path", and the cookie's path is "/".
15. If the cookie store contains a cookie with the same name, 17. If the cookie store contains a cookie with the same name,
domain, and path as the newly-created cookie: domain, and path as the newly-created cookie:
1. Let old-cookie be the existing cookie with the same name, 1. Let old-cookie be the existing cookie with the same name,
domain, and path as the newly-created cookie. (Notice that domain, and path as the newly-created cookie. (Notice that
this algorithm maintains the invariant that there is at most this algorithm maintains the invariant that there is at most
one such cookie.) one such cookie.)
2. If the newly-created cookie was received from a "non-HTTP" 2. If the newly-created cookie was received from a "non-HTTP"
API and the old-cookie's http-only-flag is true, abort these API and the old-cookie's http-only-flag is true, abort these
steps and ignore the newly created cookie entirely. steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly-created cookie to 3. Update the creation-time of the newly-created cookie to
match the creation-time of the old-cookie. match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store. 4. Remove the old-cookie from the cookie store.
16. Insert the newly-created cookie into the cookie store. 18. Insert the newly-created cookie into the cookie store.
A cookie is "expired" if the cookie has an expiry date in the past. A cookie is "expired" if the cookie has an expiry date in the past.
The user agent MUST evict all expired cookies from the cookie store The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store. if, at any time, an expired cookie exists in the cookie store.
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the number of cookies sharing a domain field exceeds cookie store if the number of cookies sharing a domain field exceeds
some implementation-defined upper bound (such as 50 cookies). some implementation-defined upper bound (such as 50 cookies).
skipping to change at page 27, line 37 skipping to change at page 33, line 5
4. All cookies. 4. All cookies.
If two cookies have the same removal priority, the user agent MUST If two cookies have the same removal priority, the user agent MUST
evict the cookie with the earliest last-access date first. evict the cookie with the earliest last-access date first.
When "the current session is over" (as defined by the user agent), When "the current session is over" (as defined by the user agent),
the user agent MUST remove from the cookie store all cookies with the the user agent MUST remove from the cookie store all cookies with the
persistent-flag set to false. persistent-flag set to false.
5.4. The Cookie Header 5.5. The Cookie Header
The user agent includes stored cookies in the Cookie HTTP request The user agent includes stored cookies in the Cookie HTTP request
header. header.
When the user agent generates an HTTP request, the user agent MUST When the user agent generates an HTTP request, the user agent MUST
NOT attach more than one Cookie header field. NOT attach more than one Cookie header field.
A user agent MAY omit the Cookie header in its entirety. For A user agent MAY omit the Cookie header in its entirety. For
example, the user agent might wish to block sending cookies during example, the user agent might wish to block sending cookies during
"third-party" requests from setting cookies (see Section 7.1). "third-party" requests from setting cookies (see Section 7.1).
skipping to change at page 28, line 38 skipping to change at page 34, line 5
NOTE: The notion of a "secure" protocol is not defined by this NOTE: The notion of a "secure" protocol is not defined by this
document. Typically, user agents consider a protocol secure document. Typically, user agents consider a protocol secure
if the protocol makes use of transport-layer security, such as if the protocol makes use of transport-layer security, such as
SSL or TLS. For example, most user agents consider "https" to SSL or TLS. For example, most user agents consider "https" to
be a scheme that denotes a secure protocol. be a scheme that denotes a secure protocol.
* If the cookie's http-only-flag is true, then exclude the * If the cookie's http-only-flag is true, then exclude the
cookie if the cookie-string is being generated for a "non- cookie if the cookie-string is being generated for a "non-
HTTP" API (as defined by the user agent). HTTP" API (as defined by the user agent).
* If the cookie's same-site-flag is not "None", and the HTTP
request is cross-site (as defined in Section 5.2) then exclude
the cookie unless all of the following statements hold:
1. The same-site-flag is "Lax"
2. The HTTP request's method is "safe".
3. The HTTP request's target browsing context is a top-level
browsing context.
2. The user agent SHOULD sort the cookie-list in the following 2. The user agent SHOULD sort the cookie-list in the following
order: order:
* Cookies with longer paths are listed before cookies with * Cookies with longer paths are listed before cookies with
shorter paths. shorter paths.
* Among cookies that have equal-length path fields, cookies with * Among cookies that have equal-length path fields, cookies with
earlier creation-times are listed before cookies with later earlier creation-times are listed before cookies with later
creation-times. creation-times.
skipping to change at page 30, line 49 skipping to change at page 36, line 29
Particularly worrisome are so-called "third-party" cookies. In Particularly worrisome are so-called "third-party" cookies. In
rendering an HTML document, a user agent often requests resources rendering an HTML document, a user agent often requests resources
from other servers (such as advertising networks). These third-party from other servers (such as advertising networks). These third-party
servers can use cookies to track the user even if the user never servers can use cookies to track the user even if the user never
visits the server directly. For example, if a user visits a site visits the server directly. For example, if a user visits a site
that contains content from a third party and then later visits that contains content from a third party and then later visits
another site that contains content from the same third party, the another site that contains content from the same third party, the
third party can track the user between the two sites. third party can track the user between the two sites.
Some user agents restrict how third-party cookies behave. For Given this risk to user privacy, some user agents restrict how third-
example, some of these user agents refuse to send the Cookie header party cookies behave, and those restrictions vary widly. For
in third-party requests. Others refuse to process the Set-Cookie instance, user agents might block third-party cookies entirely by
header in responses to third-party requests. User agents vary widely refusing to send Cookie headers or process Set-Cookie headers during
in their third-party cookie policies. This document grants user third-party requests. They might take a less draconian approach by
agents wide latitude to experiment with third-party cookie policies partitioning cookies based on the first-party context, sending one
that balance the privacy and compatibility needs of their users. set of cookies to a given third party in one first-party context, and
However, this document does not endorse any particular third-party another to the same third party in another.
cookie policy.
This document grants user agents wide latitude to experiment with
third-party cookie policies that balance the privacy and
compatibility needs of their users. However, this document does not
endorse any particular third-party cookie policy.
Third-party cookie blocking policies are often ineffective at Third-party cookie blocking policies are often ineffective at
achieving their privacy goals if servers attempt to work around their achieving their privacy goals if servers attempt to work around their
restrictions to track users. In particular, two collaborating restrictions to track users. In particular, two collaborating
servers can often track users without using cookies at all by servers can often track users without using cookies at all by
injecting identifying information into dynamic URLs. injecting identifying information into dynamic URLs.
7.2. User Controls 7.2. User Controls
User agents SHOULD provide users with a mechanism for managing the User agents SHOULD provide users with a mechanism for managing the
skipping to change at page 36, line 5 skipping to change at page 41, line 43
reaches its storage limit, the user agent will be forced to evict reaches its storage limit, the user agent will be forced to evict
some cookies. Servers SHOULD NOT rely upon user agents retaining some cookies. Servers SHOULD NOT rely upon user agents retaining
cookies. cookies.
8.7. Reliance on DNS 8.7. Reliance on DNS
Cookies rely upon the Domain Name System (DNS) for security. If the Cookies rely upon the Domain Name System (DNS) for security. If the
DNS is partially or fully compromised, the cookie protocol might fail DNS is partially or fully compromised, the cookie protocol might fail
to provide the security properties required by applications. to provide the security properties required by applications.
8.8. SameSite Cookies
8.8.1. Defense in depth
"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of
a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.
Developers are strongly encouraged to deploy the usual server-side
defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.
Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.
8.8.2. Top-level Navigations
Setting the "SameSite" attribute in "strict" mode provides robust
defense in depth against CSRF attacks, but has the potential to
confuse users unless sites' developers carefully ensure that their
cookie-based session management systems deal reasonably well with
top-level navigations.
Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://example.com/". They might expect
that clicking on an emailed link to "https://projects.com/secret/
project" would show them the secret project that they're authorized
to see, but if "projects.com" has marked their session cookies as
"SameSite", then this cross-site navigation won't send them along
with the request. "projects.com" will render a 404 error to avoid
leaking secret information, and the user will be quite confused.
Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptually
granting "read" access, another granting "write" access. The latter
could be marked as "SameSite", and its absence would prompt a
reauthentication step before executing any non-idempotent action.
The former could drop the "SameSite" attribute entirely, or choose
the "Lax" version of enforcement, in order to allow users access to
data via top-level navigation.
8.8.3. Mashups and Widgets
The "SameSite" attribute is inappropriate for some important use-
cases. In particular, note that content intended for embedding in a
cross-site contexts (social networking widgets or commenting
services, for instance) will not have access to same-site cookies.
Cookies may be required for requests triggered in these cross-site
contexts in order to provide seamless functionality that relies on a
user's state.
Likewise, some forms of Single-Sign-On might require cookie-based
authentication in a cross-site context; these mechanisms will not
function as intended with same-site cookies.
8.8.4. Server-controlled
SameSite cookies in and of themselves don't do anything to address
the general privacy concerns outlined in Section 7.1 of [RFC6265].
The "SameSite" attribute is set by the server, and serves to mitigate
the risk of certain kinds of attacks that the server is worried
about. The user is not involved in this decision. Moreover, a
number of side-channels exist which could allow a server to link
distinct requests even in the absence of cookies. Connection and/or
socket pooling, Token Binding, and Channel ID all offer explicit
methods of identification that servers could take advantage of.
9. IANA Considerations 9. IANA Considerations
The permanent message header field registry (see [RFC3864]) needs to The permanent message header field registry (see [RFC3864]) needs to
be updated with the following registrations. be updated with the following registrations.
9.1. Cookie 9.1. Cookie
Header field name: Cookie Header field name: Cookie
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 5.4) Specification document: this specification (Section 5.5)
9.2. Set-Cookie 9.2. Set-Cookie
Header field name: Set-Cookie Header field name: Set-Cookie
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 5.2) Specification document: this specification (Section 5.3)
10. References 10. References
10.1. Normative References 10.1. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>.
[PSL] "Public Suffix List", n.d., <https://publicsuffix.org/
list/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>. <http://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>. <http://www.rfc-editor.org/info/rfc2616>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Costello, A., "Internationalizing Domain Names in
"Internationalizing Domain Names in Applications (IDNA)", Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490,
RFC 3490, DOI 10.17487/RFC3490, March 2003, March 2003, <http://www.rfc-editor.org/info/rfc3490>.
<http://www.rfc-editor.org/info/rfc3490>.
See Section 6.3 for an explanation why the normative
reference to an obsoleted specification is needed.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
DOI 10.17487/RFC4790, March 2007, DOI 10.17487/RFC4790, March 2007,
<http://www.rfc-editor.org/info/rfc4790>. <http://www.rfc-editor.org/info/rfc4790>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[USASCII] Institute, A., "Coded Character Set -- 7-bit American [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
Standard Code for Information Interchange", 1986, <ANSI DOI 10.17487/RFC6454, December 2011,
X3.4>. <http://www.rfc-editor.org/info/rfc6454>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[SERVICE-WORKERS]
Russell, A., Song, J., and J. Archibald, "Service
Workers", n.d., <http://www.w3.org/TR/service-workers/>.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
[Aggarwal2010] [Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern "An Analysis of Private Browsing Modes in Modern
Browsers", 2010, Browsers", 2010,
<http://www.usenix.org/events/sec10/tech/full_papers/ <http://www.usenix.org/events/sec10/tech/full_papers/
Aggarwal.pdf>. Aggarwal.pdf>.
[app-isolation]
Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
"App Isolation - Get the Security of Multiple Browsers
with Just One", 2011,
<http://www.collinjackson.com/research/papers/
appisolation.pdf>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008, for Cross-Site Request Forgery",
DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7,
ACM CCS '08: Proceedings of the 15th ACM conference on
Computer and communications security (pages 75-88),
October 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>. <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[draft-ietf-httpbis-cookie-alone] [I-D.ietf-httpbis-cookie-alone]
West, M., "Deprecate modification of 'secure' cookies from West, M., "Deprecate modification of 'secure' cookies from
non-secure origins", September 2016, non-secure origins", draft-ietf-httpbis-cookie-alone-01
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie- (work in progress), September 2016.
alone-01>.
[draft-ietf-httpbis-cookie-prefixes]
West, M., "Cookie Prefixes", February 2016,
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie-
prefixes-00>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [I-D.ietf-httpbis-cookie-prefixes]
Politics", ACM ACM Transactions on Internet Technology West, M., "Cookie Prefixes", draft-ietf-httpbis-cookie-
Vol. 1, #2, November 2001, prefixes-00 (work in progress), February 2016.
<http://arxiv.org/abs/cs.SE/0105018>.
[Netscape] [I-D.ietf-httpbis-cookie-same-site]
Corp., N., "Persistent Client State -- HTTP Cookies", West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf-
1999, <http://web.archive.org/web/20020803110822/http://wp httpbis-cookie-same-site-00 (work in progress), June 2016.
.netscape.com/newsref/std/cookie_spec.html>.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [prerendering]
Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, Bentzel, C., "Chrome Prerendering", n.d.,
<http://www.rfc-editor.org/info/rfc2109>. <https://www.chromium.org/developers/design-documents/
prerender>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000,
<http://www.rfc-editor.org/info/rfc2965>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <http://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
skipping to change at page 39, line 14 skipping to change at page 47, line 14
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
<http://www.rfc-editor.org/info/rfc5895>. <http://www.rfc-editor.org/info/rfc5895>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <http://www.rfc-editor.org/info/rfc6265>.
[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
<http://www.rfc-editor.org/info/rfc7034>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", UNICODE Unicode Technical Standards # 46, Processing", UNICODE Unicode Technical Standards # 46,
2010, <http://unicode.org/reports/tr46/>. June 2016, <http://unicode.org/reports/tr46/>.
Appendix A. Changes Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00 A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes. o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01 A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to o Fixes to formatting caused by mistakes in the initial port to
skipping to change at page 39, line 41 skipping to change at page 47, line 45
* https://github.com/httpwg/http-extensions/issues/246 * https://github.com/httpwg/http-extensions/issues/246
o Addresses errata 3444 by updating the "path-value" and "extension- o Addresses errata 3444 by updating the "path-value" and "extension-
av" grammar, errata 4148 by updating the "day-of-month", "year", av" grammar, errata 4148 by updating the "day-of-month", "year",
and "time" grammar, and errata 3663 by adding the requested note. and "time" grammar, and errata 3663 by adding the requested note.
https://www.rfc-editor.org/errata_search.php?rfc=6265 https://www.rfc-editor.org/errata_search.php?rfc=6265
o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations
section: https://github.com/httpwg/http-extensions/issues/247 section: https://github.com/httpwg/http-extensions/issues/247
o Merged the recommendations from [draft-ietf-httpbis-cookie-alone], o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone],
removing the ability for a non-secure origin to set cookies with a removing the ability for a non-secure origin to set cookies with a
'secure' flag, and to overwrite cookies whose 'secure' flag is 'secure' flag, and to overwrite cookies whose 'secure' flag is
true. true.
o Merged the recommendations from o Merged the recommendations from
[draft-ietf-httpbis-cookie-prefixes], adding "__Secure-" and [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and
"__Host-" cookie name prefix processing instructions. "__Host-" cookie name prefix processing instructions.
A.3. draft-ietf-httpbis-rfc6265bis-02
o Merged the recommendations from
[I-D.ietf-httpbis-cookie-same-site], adding support for the
"SameSite" attribute.
o Closed a number of editorial bugs:
* Clarified address bar behavior for SameSite cookies:
https://github.com/httpwg/http-extensions/issues/201
* Added the word "Cookies" to the document's name:
https://github.com/httpwg/http-extensions/issues/204
* Clarified that the "__Host-" prefix requires an explicit "Path"
attribute: https://github.com/httpwg/http-extensions/issues/222
* Expanded the options for dealing with third-party cookies to
include a brief mention of partitioning based on first-party:
https://github.com/httpwg/http-extensions/issues/248
* Noted that double-quotes in cookie values are part of the
value, and are not stripped: https://github.com/httpwg/http-
extensions/issues/295
* Fixed the "site for cookies" algorithm to return something that
makes sense: https://github.com/httpwg/http-extensions/
issues/302
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document is a minor update of RFC 6265, adding small features, This document is a minor update of RFC 6265, adding small features,
and aligning the specification with the reality of today's and aligning the specification with the reality of today's
deployments. Here, we're standing upon the shoulders of giants. deployments. Here, we're standing upon the shoulders of giants.
Authors' Addresses Authors' Addresses
Adam Barth Adam Barth
Google, Inc Google, Inc
 End of changes. 57 change blocks. 
146 lines changed or deleted 533 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/