draft-ietf-httpbis-cookie-same-site-00.txt   draft-ietf-httpbis-cookie-same-site-latest.txt 
HTTP Working Group M. West HTTP Working Group M. West
Internet-Draft Google, Inc Internet-Draft Google, Inc
Updates: 6265 (if approved) M. Goodwin Updates: 6265 (if approved) M. Goodwin
Intended status: Standards Track Mozilla Intended status: Standards Track Mozilla
Expires: December 22, 2016 June 20, 2016 Expires: January 7, 2025 July 6, 2018
Same-Site Cookies Same-Site Cookies
draft-ietf-httpbis-cookie-same-site-00 draft-ietf-httpbis-cookie-same-site-latest
Abstract Abstract
This document updates RFC6265 by defining a "SameSite" attribute This document updates RFC6265 by defining a "SameSite" attribute
which allows servers to assert that a cookie ought not to be sent which allows servers to assert that a cookie ought not to be sent
along with cross-site requests. This assertion allows user agents to along with cross-site requests. This assertion allows user agents to
mitigate the risk of cross-origin information leakage, and provides mitigate the risk of cross-origin information leakage, and provides
some protection against cross-site request forgery attacks. some protection against cross-site request forgery attacks.
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/ [1].
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 [2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/cookie-same-site. https://github.com/httpwg/http-extensions/labels/cookie-same-site
[3].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2016. This Internet-Draft will expire on January 7, 2025.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and notation . . . . . . . . . . . . . . . . . . . 4 2. Terminology and notation . . . . . . . . . . . . . . . . . . 4
2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 5 2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 5
2.1.1. Document-based requests . . . . . . . . . . . . . . . 5 2.1.1. Document-based requests . . . . . . . . . . . . . . . 5
2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6 2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6
3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 7 3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8 3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8
4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8 4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8
4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . . 8 4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . 8
4.1.1. "Strict" and "Lax" enforcement . . . . . . . . . . . . 8 4.1.1. "Strict" and "Lax" enforcement . . . . . . . . . . . 9
4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9 4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9
4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 9 4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 10
5. Authoring Considerations . . . . . . . . . . . . . . . . . . . 10 5. Authoring Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Defense in depth . . . . . . . . . . . . . . . . . . . . . 10 5.1. Defense in depth . . . . . . . . . . . . . . . . . . . . 10
5.2. Top-level Navigations . . . . . . . . . . . . . . . . . . 10 5.2. Top-level Navigations . . . . . . . . . . . . . . . . . . 11
5.3. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 11 5.3. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Server-controlled . . . . . . . . . . . . . . . . . . . . 11 6.1. Server-controlled . . . . . . . . . . . . . . . . . . . . 11
6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . . 11 6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes since draft-ietf-httpbis-cookie-same-site-00 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Section 8.2 of [RFC6265] eloquently notes that cookies are a form of Section 8.2 of [RFC6265] eloquently notes that cookies may be
ambient authority, attached by default to requests the user agent employed as a form of ambient authority, attached by default to
sends on a user's behalf. Even when an attacker doesn't know the requests the user agent sends on a user's behalf. Even when an
contents of a user's cookies, she can still execute commands on the attacker doesn't know the contents of a user's cookies, she can still
user's behalf (and with the user's authority) by asking the user execute commands on the user's behalf (and with the user's authority)
agent to send HTTP requests to unwary servers. by asking the user agent to send HTTP requests to unwary servers.
These malicious requests will include any of the user's previously-
set cookies, and therefore can be difficult to distinguish from
benign requests on the user's behalf.
Here, we update [RFC6265] with a simple mitigation strategy that Here, we update [RFC6265] with a simple mitigation strategy that
allows servers to declare certain cookies as "same-site", meaning allows servers to declare certain cookies as "same-site", meaning
they should not be attached to "cross-site" requests (as defined in they should not be attached to "cross-site" requests (as defined in
section 2.1). section 2.1 of this specification).
Note that the mechanism outlined here is backwards compatible with Note that the mechanism outlined here is backwards compatible with
the existing cookie syntax. Servers may serve these cookies to all the existing cookie syntax. Servers may serve these cookies to all
user agents; those that do not support the "SameSite" attribute will user agents; those that do not support the "SameSite" attribute will
simply store a cookie which is attached to all relevant requests, simply store a cookie which is attached to all relevant requests,
just as they do today. just as they do today.
1.1. Goals 1.1. Goals
These cookies are intended to provide a solid layer of defense-in- Same-site cookies are intended to provide a solid layer of defense-
depth against attacks which require embedding an authenticated in-depth against attacks which require embedding an authenticated
request into an attacker-controlled context: request into an attacker-controlled context:
1. Timing attacks which yield cross-origin information leakage (such 1. Timing attacks which yield cross-origin information leakage (such
as those detailed in [pixel-perfect]) can be substantially as those detailed in [pixel-perfect]) can be substantially
mitigated by setting the "SameSite" attribute on authentication mitigated by setting the "SameSite" attribute on authentication
cookies. The attacker will only be able to embed unauthenticated cookies. The attacker will only be able to embed unauthenticated
resources, as embedding mechanisms such as "<iframe>" will yield resources, as embedding mechanisms such as "<iframe>" will yield
cross-site requests. cross-site requests.
2. Cross-site script inclusion (XSSI) attacks are likewise mitigated 2. Cross-site script inclusion (XSSI) attacks are likewise mitigated
by setting the "SameSite" attribute on authentication cookies. by setting the "SameSite" attribute on authentication cookies.
skipping to change at page 4, line 7 skipping to change at page 4, line 9
site". site".
4. Same-site cookies have some marginal value for policy or 4. Same-site cookies have some marginal value for policy or
regulatory purposes, as cookies which are not delivered with regulatory purposes, as cookies which are not delivered with
cross-site requests cannot be directly used for tracking cross-site requests cannot be directly used for tracking
purposes. It may be valuable for an origin to assert that its purposes. It may be valuable for an origin to assert that its
cookies should not be sent along with cross-site requests in cookies should not be sent along with cross-site requests in
order to limit its exposure to non-technical risk. order to limit its exposure to non-technical risk.
1.2. Examples 1.2. Examples
Same-site cookies are set via the "SameSite" attribute in the Same-site cookies are set via the "SameSite" attribute in the "Set-
"Set-Cookie" header field. That is, given a server's response to a Cookie" header field. That is, given a server's response to a user
user agent which contains the following header field: agent which contains the following header field:
Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict
Subsequent requests from that user agent can be expected to contain Subsequent requests from that user agent can be expected to contain
the following header field if and only if both the requested resource the following header field if and only if both the requested resource
and the resource in the top-level browsing context match the cookie. and the resource in the top-level browsing context match the cookie.
Cookie: SID=31d4d96e407aad42
2. Terminology and notation 2. Terminology and notation
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].
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
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 terms "active document", "ancestor browsing context", "browsing The terms "active document", "ancestor browsing context", "browsing
context", "document", "WorkerGlobalScope", "sandboxed origin browsing context", "dedicated worker", "Document", "WorkerGlobalScope",
context flag", "parent browsing context", "the worker's Documents", "sandboxed origin browsing context flag", "parent browsing context",
"nested browsing context", and "top-level browsing context" are "shared worker", "the worker's Documents", "nested browsing context",
defined in [HTML]. and "top-level browsing context" are defined in [HTML].
"Service Workers" are defined in the Service Workers specification "Service Workers" are defined in the Service Workers specification
[SERVICE-WORKERS]. [SERVICE-WORKERS].
The term "origin", the mechanism of deriving an origin from a URI, The term "origin", the mechanism of deriving an origin from a URI,
and the "the same" matching algorithm for origins are defined in and the "the same" matching algorithm for origins are defined in
[RFC6454]. [RFC6454].
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
defined in Section 4.2.1 of [RFC7231]. defined in Section 4.2.1 of [RFC7231].
The term "public suffix" is defined in a note in Section 5.3 of 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". For [RFC6265] as "a domain that is controlled by a public registry", and
example, "example.com"'s public suffix is "com". User agents SHOULD are also know as "effective top-level domains" (eTLDs). For example,
use an up-to-date public suffix list, such as the one maintained by "example.com"'s public suffix is "com". User agents SHOULD use an
Mozilla at [PSL]. up-to-date public suffix list, such as the one maintained by Mozilla
at [PSL].
An origin's "registrable domain" is the origin's host's public suffix An origin's "registered domain" is the origin's host's public suffix
plus the label to its left. That is, "https://www.example.com"'s plus the label to its left. That is, for "https://www.example.com",
registrable domain is "example.com". This concept is defined more the public suffix is "com", and the registered domain is
rigorously in [PSL]. "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", The term "request", as well as a request's "client", "current url",
"method", and "target browsing context", are defined in [FETCH]. "method", and "target browsing context", are defined in [FETCH].
2.1. "Same-site" and "cross-site" Requests 2.1. "Same-site" and "cross-site" Requests
A request is "same-site" if its target's URI's origin's registrable A request is "same-site" if its target's URI's origin's registered
domain is an exact match for the request's initiator's "site for domain is an exact match for the request's client's "site for
cookies", and "cross-site" otherwise. To be more precise, for a cookies" or if the request has no client, and "cross-site" otherwise.
given request ("request"), the following algorithm returns To be more precise, for a given request ("request"), the following
"same-site" or "cross-site": algorithm returns "same-site" or "cross-site":
1. If "request"'s client is "null", return "same-site". 1. If "request"'s client is "null", return "same-site".
2. Let "site" be "request"'s client's "site for cookies" (as defined 2. Let "site" be "request"'s client's "site for cookies" (as defined
in the following sections). in the following sections).
3. Let "target" be the registrable domain of "request"'s current 3. Let "target" be the registered domain of "request"'s current url.
url.
4. If "site" is an exact match for "target", return "same-site". 4. If "site" is an exact match for "target", return "same-site".
5. Return "cross-site". 5. Return "cross-site".
2.1.1. Document-based requests 2.1.1. Document-based requests
The URI displayed in a user agent's address bar is the only security The URI displayed in a user agent's address bar is the only security
context directly exposed to users, and therefore the only signal context directly exposed to users, and therefore the only signal
users can reasonably rely upon to determine whether or not they trust users can reasonably rely upon to determine whether or not they trust
a particular website. The registrable domain of that URI's origin a particular website. The registered domain of that URI's origin
represents the context in which a user most likely believes represents the context in which a user most likely believes
themselves to be interacting. We'll label this domain the "top-level themselves to be interacting. We'll label this domain the "top-level
site". site".
For a document displayed in a top-level browsing context, we can stop 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. here: the document's "site for cookies" is the top-level site.
For documents which are displayed in nested browsing contexts, we For documents which are displayed in nested browsing contexts, we
need to audit the origins of each of a document's ancestor browsing need to audit the origins of each of a document's ancestor browsing
contexts' active documents in order to account for the "multiple- contexts' active documents in order to account for the "multiple-
nested scenarios" described in Section 4 of [RFC7034]. These nested scenarios" described in Section 4 of [RFC7034]. These
document's "site for cookies" is the top-level site if and only if 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 the document and each of its ancestor documents' origins have the
same registrable domain as the top-level site. Otherwise its "site same registered domain as the top-level site. Otherwise its "site
for cookies" is the empty string. for cookies" is the empty string.
Given a Document ("document"), the following algorithm returns its Given a Document ("document"), the following algorithm returns its
"site for cookies" (either a registrable domain, or the empty "site for cookies" (either a registered domain, or the empty string):
string):
1. Let "top-document" be the active document in "document"'s 1. Let "top-document" be the active document in "document"'s
browsing context's top-level browsing context. browsing context's top-level browsing context.
2. Let "top-origin" be the origin of "top-document"'s URI if 2. Let "top-origin" be the origin of "top-document"'s URI if "top-
"top-document"'s sandboxed origin browsing context flag is set, document"'s sandboxed origin browsing context flag is set, and
and "top-document"'s origin otherwise. "top-document"'s origin otherwise.
3. Let "documents" be a list containing "document" and each of 3. Let "documents" be a list containing "document" and each of
"document"'s ancestor browsing contexts' active documents. "document"'s ancestor browsing contexts' active documents.
4. For each "item" in "documents": 4. For each "item" in "documents":
1. Let "origin" be the origin of "item"'s URI if "item"'s 1. Let "origin" be the origin of "item"'s URI if "item"'s
sandboxed origin browsing context flag is set, and "item"'s sandboxed origin browsing context flag is set, and "item"'s
origin otherwise. origin otherwise.
2. If "origin"'s host's registrable domain is not an exact match 2. If "origin"'s host's registered domain is not an exact match
for "top-origin"'s host's registrable domain, return the for "top-origin"'s host's registered domain, return the empty
empty string. string.
5. Return "top-site". 5. Return "top-site".
2.1.2. Worker-based requests 2.1.2. Worker-based requests
Worker-driven requests aren't as clear-cut as document-driven Worker-driven requests aren't as clear-cut as document-driven
requests, as there isn't a clear link between a top-level browsing requests, as there isn't a clear link between a top-level browsing
context and a worker. This is especially true for Service Workers context and a worker. This is especially true for Service Workers
[SERVICE-WORKERS], which may execute code in the background, without [SERVICE-WORKERS], which may execute code in the background, without
any document visible at all. any document visible at all.
skipping to change at page 6, line 49 skipping to change at page 7, line 6
worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
their "site for cookies" as that document's "site for cookies". their "site for cookies" as that document's "site for cookies".
Shared workers may be bound to multiple documents at once. As it is Shared workers may be bound to multiple documents at once. As it is
quite possible for those documents to have distinct "site for cookie" quite possible for those documents to have distinct "site for cookie"
values, the worker's "site for cookies" will be the empty string in 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 cases where the values diverge, and the shared value in cases where
the values agree. the values agree.
Given a WorkerGlobalScope ("worker"), the following algorithm returns Given a WorkerGlobalScope ("worker"), the following algorithm returns
its "site for cookies" (either a registrable domain, or the empty its "site for cookies" (either a registered domain, or the empty
string): string):
1. Let "site" be "worker"'s origin's host's registrable domain. 1. Let "site" be "worker"'s origin's host's registered domain.
2. For each "document" in "worker"'s Documents: 2. For each "document" in "worker"'s Documents:
1. Let "document-site" be "document"'s "site for cookies" (as 1. Let "document-site" be "document"'s "site for cookies" (as
defined in Section 2.1.1). defined in Section 2.1.1).
2. If "document-site" is not an exact match for "site", return 2. If "document-site" is not an exact match for "site", return
the empty string. the empty string.
3. Return "site". 3. Return "site".
2.1.2.2. Service Workers 2.1.2.2. Service Workers
Service Workers are more complicated, as they act as a completely Service Workers are more complicated, as they act as a completely
separate execution context with only tangential relationship to the separate execution context with only tangential relationship to the
Document which registered them. Document which registered them.
Requests which simply pass through a service worker will be handled Requests which simply pass through a service worker will be handled
as described above: the request's client will be the Document or as described above: the request's client will be the Document or
Worker which initiated the request, and its "site for cookies" will Worker which initiated the request, and its "site for cookies" will
be those defined in Section 2.1.1 and Section 2.1.2.1 be those defined in Section 2.1.1 and Section 2.1.2.1
Requests which are initiated by the Service Worker itself (via a Requests which are initiated by the Service Worker itself (via a
direct call to "fetch()", for instance), on the other hand, will have direct call to "fetch()", for instance), on the other hand, will have
a client which is a ServiceWorkerGlobalScope. Its "site for cookies" a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
will be the registrable domain of the Service Worker's URI. will be the registered domain of the Service Worker's URI.
Given a ServiceWorkerGlobalScope ("worker"), the following algorithm Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
returns its "site for cookies" (either a registrable domain, or the returns its "site for cookies" (either a registered domain, or the
empty string): empty string):
1. Return "worker"'s origin's host's registrable domain. 1. Return "worker"'s origin's host's registered domain.
3. Server Requirements 3. Server Requirements
This section describes extensions to [RFC6265] necessary to implement This section describes extensions to [RFC6265] necessary to implement
the server-side requirements of the "SameSite" attribute. the server-side requirements of the "SameSite" attribute.
3.1. Grammar 3.1. Grammar
Add "SameSite" to the list of accepted attributes in the "Set-Cookie" Add "SameSite" to the list of accepted attributes in the "Set-Cookie"
header field's value by replacing the "cookie-av" token definition in header field's value by replacing the "cookie-av" token definition in
Section 4.1.1 of [RFC6265] with the following ABNF grammar: Section 4.1.1 of [RFC6265] with the following ABNF grammar:
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 /
samesite-av / extension-av samesite-av / extension-av
samesite-av = "SameSite" / "SameSite=" samesite-value samesite-av = "SameSite=" samesite-value
samesite-value = "Strict" / "Lax" samesite-value = "Strict" / "Lax"
3.2. Semantics of the "SameSite" Attribute (Non-Normative) 3.2. Semantics of the "SameSite" Attribute (Non-Normative)
The "SameSite" attribute limits the scope of the cookie such that it The "SameSite" attribute limits the scope of the cookie such that it
will only be attached to requests if those requests are "same-site", will only be attached to requests if those requests are same-site, as
as defined by the algorithm in Section 2.1. For example, requests defined by the algorithm in Section 2.1. For example, requests for
for "https://example.com/sekrit-image" will attach same-site cookies "https://example.com/sekrit-image" will attach same-site cookies if
if and only if initiated from a context whose "site for cookies" is and only if initiated from a context whose "site for cookies" is
"example.com". "example.com".
If the "SameSite" attribute's value is "Strict", or if the value is If the "SameSite" attribute's value is "Strict", the cookie will only
invalid, the cookie will only be sent along with "same-site" be sent along with "same-site" requests. If the value is "Lax", the
requests. If the value is "Lax", the cookie will be sent with "same- cookie will be sent with same-site requests, and with "cross-site"
site" requests, and with "cross-site" top-level navigations, as top-level navigations, as described in Section 4.1.1. If the
described in Section 4.1.1. "SameSite" attribute's value is neither of these, the cookie will be
ignored.
The changes to the "Cookie" header field suggested in Section 4.3 The changes to the "Cookie" header field suggested in Section 4.3
provide additional detail. provide additional detail.
4. User Agent Requirements 4. User Agent Requirements
This section describes extensions to [RFC6265] necessary in order to This section describes extensions to [RFC6265] necessary in order to
implement the client-side requirements of the "SameSite" attribute. implement the client-side requirements of the "SameSite" attribute.
4.1. The "SameSite" attribute 4.1. The "SameSite" attribute
skipping to change at page 8, line 46 skipping to change at page 9, line 7
1. If "cookie-av"'s "attribute-value" is not a case-insensitive 1. If "cookie-av"'s "attribute-value" is not a case-insensitive
match for "Strict" or "Lax", ignore the "cookie-av". match for "Strict" or "Lax", ignore the "cookie-av".
2. Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is 2. Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is
a case-insensitive match for "Lax", and "Strict" otherwise. a case-insensitive match for "Lax", and "Strict" otherwise.
3. Append an attribute to the "cookie-attribute-list" with an 3. Append an attribute to the "cookie-attribute-list" with an
"attribute-name" of "SameSite" and an "attribute-value" of "attribute-name" of "SameSite" and an "attribute-value" of
"enforcement". "enforcement".
4.1.1. "Strict" and "Lax" enforcement 4.1.1. "Strict" and "Lax" enforcement
By default, same-site cookies will not be sent along with top-level Same-site cookies in "Strict" enforcement mode will not be sent along
navigations. As discussed in Section 5.2, this might or might not be with top-level navigations which are triggered from a cross-site
compatible with existing session management systems. In the document context. As discussed in Section 5.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 interests of providing a drop-in mechanism that mitigates the risk of
CSRF attacks, developers may set the "SameSite" attribute in a "Lax" CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
enforcement mode that carves out an exception which sends same-site enforcement mode that carves out an exception which sends same-site
cookies along with cross-site requests if and only if they are top- cookies along with cross-site requests if and only if they are top-
level navigations which use a "safe" (in the [RFC7231] sense) HTTP level navigations which use a "safe" (in the [RFC7231] sense) HTTP
method. method.
Lax enforcement provides reasonable defense in depth against CSRF Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but do not attacks that rely on unsafe HTTP methods (like "POST"), but does not
offer a robust defense against CSRF as a general category of attack: offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level 1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as navigations in order to create a "same-site" request (as
described in section 2.1), which is only a speedbump along the described in section 2.1), which is only a speedbump along the
road to exploitation. road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be 2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user exploited to create "same-site" requests without the risk of user
detection. detection.
skipping to change at page 9, line 31 skipping to change at page 9, line 41
such as that described in Section 5.2 to mitigate the risk of CSRF such as that described in Section 5.2 to mitigate the risk of CSRF
more completely. more completely.
4.2. Monkey-patching the Storage Model 4.2. Monkey-patching the Storage Model
Note: There's got to be a better way to specify this. Until I figure Note: There's got to be a better way to specify this. Until I figure
out what that is, monkey-patching! out what that is, monkey-patching!
Alter Section 5.3 of [RFC6265] as follows: Alter Section 5.3 of [RFC6265] as follows:
1. Add "samesite-flag" to the list of fields stored for each cookie. 1. Add "samesite-flag" to the list of each cookie's fields defined
This field's value is one of "None", "Strict", or "Lax". in the first paragraph. Note: this field's value is one of
"None", "Strict", or "Lax".
2. Before step 11 of the current algorithm, add the following: 2. Before step 11 of the current algorithm, add the following:
1. If the "cookie-attribute-list" contains an attribute with an 1. If the "cookie-attribute-list" contains an attribute with an
"attribute-name" of "SameSite", set the cookie's "attribute-name" of "SameSite", set the cookie's "samesite-
"samesite-flag" to "attribute-value" ("Strict" or "Lax"). flag" to "attribute-value" ("Strict" or "Lax"). Otherwise,
Otherwise, set the cookie's "samesite-flag" to "None". set the cookie's "samesite-flag" to "None".
2. If the cookie's "samesite-flag" is not "None", and the 2. If the cookie's "samesite-flag" is not "None", and the
request which generated the cookie's client's "site for request which generated the cookie's client's "site for
cookies" is not an exact match for "request-uri"'s host's cookies" is not an exact match for "request-uri"'s host's
registrable domain, then abort these steps and ignore the registered domain, then abort these steps and ignore the
newly created cookie entirely. newly created cookie entirely.
4.3. Monkey-patching the "Cookie" header 4.3. Monkey-patching the "Cookie" header
Note: There's got to be a better way to specify this. Until I figure Note: There's got to be a better way to specify this. Until I figure
out what that is, monkey-patching! out what that is, monkey-patching!
Alter Section 5.4 of [RFC6265] as follows: Alter Section 5.4 of [RFC6265] as follows:
1. Add the following requirement to the list in step 1: 1. Add the following requirement to the end of the bulleted list in
step 1:
* If the cookie's "samesite-flag" is not "None", and the HTTP * If the cookie's "samesite-flag" is not "None", and the HTTP
request is cross-site (as defined in Section 2.1 then exclude request is cross-site (as defined in Section 2.1) then exclude
the cookie unless all of the following statements hold: the cookie unless all of the following statements hold:
1. "samesite-flag" is "Lax" 1. "samesite-flag" is "Lax"
2. The HTTP request's method is "safe". 2. The HTTP request's method is "safe".
3. The HTTP request's target browsing context is a top-level 3. The HTTP request's target browsing context is a top-level
browsing context. browsing context.
Note that the modifications suggested here concern themselves only Note that the modifications suggested here concern themselves only
with the "site for cookies" of the request's client, and the with the "site for cookies" of the request's client, and the
registrable domain of the resource being requested. The cookie's registered domain of the resource being requested. The cookie's
"domain", "path", and "secure" attributes do not come into play for "domain", "path", and "secure" attributes do not come into play for
these comparisons. these comparisons.
5. Authoring Considerations 5. Authoring Considerations
5.1. Defense in depth 5.1. Defense in depth
"SameSite" cookies offer a robust defense against CSRF attack when "SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is, deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of however, prudent to ensure that this designation is not the extent of
skipping to change at page 10, line 44 skipping to change at page 11, line 10
Additionally, client-side techniques such as those described in Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are [app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies. certainly worth exploring in combination with "SameSite" cookies.
5.2. Top-level Navigations 5.2. Top-level Navigations
Setting the "SameSite" attribute in "strict" mode provides robust Setting the "SameSite" attribute in "strict" mode provides robust
defense in depth against CSRF attacks, but has the potential to defense in depth against CSRF attacks, but has the potential to
confuse users unless sites' developers carefully ensure that their confuse users unless sites' developers carefully ensure that their
session management systems deal reasonably well with top-level cookie-based session management systems deal reasonably well with
navigations. top-level navigations.
Consider the scenario in which a user reads their email at MegaCorp Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://example.com/". They might expect Inc's webmail provider "https://example.com/". They might expect
that clicking on an emailed link to that clicking on an emailed link to "https://projects.com/secret/
"https://projects.com/secret/project" would show them the secret project" would show them the secret project that they're authorized
project that they're authorized to see, but if "projects.com" has to see, but if "projects.com" has marked their session cookies as
marked their session cookies as "SameSite", then this cross-site "SameSite", then this cross-site navigation won't send them along
navigation won't send them along with the request. "projects.com" with the request. "projects.com" will render a 404 error to avoid
will render a 404 error to avoid leaking secret information, and the leaking secret information, and the user will be quite confused.
user will be quite confused.
Developers can avoid this confusion by adopting a session management Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptualy system that relies on not one, but two cookies: one conceptually
granting "read" access, another granting "write" access. The latter granting "read" access, another granting "write" access. The latter
could be marked as "SameSite", and its absence would provide a could be marked as "SameSite", and its absence would prompt a
reauthentication step before executing any non-idempotent action. reauthentication step before executing any non-idempotent action.
The former could drop the "SameSite" attribute entirely, or choose The former could drop the "SameSite" attribute entirely, or choose
the "Lax" version of enforcement, in order to allow users access to the "Lax" version of enforcement, in order to allow users access to
data via top-level navigation. data via top-level navigation.
5.3. Mashups and Widgets 5.3. Mashups and Widgets
The "SameSite" attribute is inappropriate for some important use- The "SameSite" attribute is inappropriate for some important use-
cases. In particular, note that content intended for embedding in a cases. In particular, note that content intended for embedding in a
cross-site contexts (social networking widgets or commenting cross-site contexts (social networking widgets or commenting
services, for instance) will not have access to such cookies. Cross- services, for instance) will not have access to same-site cookies.
site cookies may be required in order to provide seamless Cookies may be required for requests triggered in these cross-site
functionality that relies on a user's state. contexts in order to provide seamless functionality that relies on a
user's state.
Likewise, some forms of Single-Sign-On might require authentication Likewise, some forms of Single-Sign-On might require cookie-based
in a cross-site context; these mechanisms will not function as authentication in a cross-site context; these mechanisms will not
intended with same-site cookies. function as intended with same-site cookies.
6. Privacy Considerations 6. Privacy Considerations
6.1. Server-controlled 6.1. Server-controlled
Same-site cookies in and of themselves don't do anything to address Same-site cookies in and of themselves don't do anything to address
the general privacy concerns outlined in Section 7.1 of [RFC6265]. the general privacy concerns outlined in Section 7.1 of [RFC6265].
The attribute is set by the server, and serves to mitigate the risk The SameSite attribute is set by the server, and serves to mitigate
of certain kinds of attacks that the server is worried about. The the risk of certain kinds of attacks that the server is worried
user is not involved in this decision. Moreover, a number of side- about. The user is not involved in this decision. Moreover, a
channels exist which could allow a server to link distinct requests number of side-channels exist which could allow a server to link
even in the absence of cookies. Connection and/or socket pooling, distinct requests even in the absence of cookies. Connection and/or
Token Binding, and Channel ID all offer explicit methods of socket pooling, Token Binding, and Channel ID all offer explicit
identification that servers could take advantage of. methods of identification that servers could take advantage of.
6.2. Pervasive Monitoring 6.2. Pervasive Monitoring
As outlined in [RFC7258], pervasive monitoring is an attack. Cookies As outlined in [RFC7258], pervasive monitoring is an attack. Cookies
play a large part in enabling such monitoring, as they are play a large part in enabling such monitoring, as they are
responsible for maintaining state in HTTP connections. We considered responsible for maintaining state in HTTP connections. We considered
restricting same-site cookies to secure contexts [secure-contexts] as restricting same-site cookies to secure contexts [secure-contexts] as
a mitigation but decided against doing so, as this feature should a mitigation but decided against doing so, as same-site cookies
result in a strict reduction in the number of cookies floating around should result in a strict reduction in the number of cookies floating
in cross-site contexts. That is, even if "http://not-example.com" around in cross-site contexts. That is, even if "http://not-
embeds a resource from "http://example.com/", that resource will not example.com" embeds a resource from "http://example.com/", that
be "same-site", and "http://example.com"'s cookies simply cannot be resource will not be "same-site", and "http://example.com"'s cookies
used to correlate user behavior across distinct origins. simply cannot be used to correlate user behavior across distinct
origins.
7. References 7. References
7.1. Normative References 7.1. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d., [FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
P., and D. Denicola, "HTML", n.d., P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[PSL] "Public Suffix List", n.d., [PSL] "Public Suffix List", n.d.,
<https://publicsuffix.org/list/>. <https://publicsuffix.org/list/>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>. <https://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, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
May 2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[SERVICE-WORKERS] [SERVICE-WORKERS]
Russell, A., Song, J., and J. Archibald, "Service Russell, A., Song, J., and J. Archibald, "Service
Workers", n.d., <http://www.w3.org/TR/service-workers/>. Workers", n.d., <http://www.w3.org/TR/service-workers/>.
7.2. Informative References 7.2. Informative References
[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>.
[app-isolation] [app-isolation]
Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson, Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
"App Isolation - Get the Security of Multiple Browsers "App Isolation - Get the Security of Multiple Browsers
with Just One", n.d., <http://www.collinjackson.com/ with Just One", 2011,
research/papers/appisolation.pdf>. <http://www.collinjackson.com/research/papers/
appisolation.pdf>.
[pixel-perfect] [pixel-perfect]
Stone, P., "Pixel Perfect Timing Attacks with HTML5", Stone, P., "Pixel Perfect Timing Attacks with HTML5",
n.d., <http://www.contextis.com/documents/2/ n.d., <http://www.contextis.com/documents/2/
Browser_Timing_Attacks.pdf>. Browser_Timing_Attacks.pdf>.
[prerendering] [prerendering]
Bentzel, C., "Chrome Prerendering", n.d., <https:// Bentzel, C., "Chrome Prerendering", n.d.,
www.chromium.org/developers/design-documents/prerender>. <https://www.chromium.org/developers/design-documents/
prerender>.
[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
<https://www.rfc-editor.org/info/rfc7034>.
[samedomain-cookies] [samedomain-cookies]
Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011, Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,
<http://people.mozilla.org/~mgoodwin/SameDomain/ <http://people.mozilla.org/~mgoodwin/SameDomain/
samedomain-latest.txt>. samedomain-latest.txt>.
[secure-contexts] [secure-contexts]
West, M., "Secure Contexts", n.d., West, M., "Secure Contexts", n.d.,
<https://w3c.github.io/webappsec-secure-contexts/>. <https://w3c.github.io/webappsec-secure-contexts/>.
Appendix A. Acknowledgements 7.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/cookie-same-site
Appendix A. Changes since draft-ietf-httpbis-cookie-same-site-00
1. Cookies whose "SameSite" attribute's value is neither "Strict"
nor "Lax" are ignored.
Appendix B. Acknowledgements
The same-site cookie concept documented here is indebited to Mark The same-site cookie concept documented here is indebited to Mark
Goodwin's and Joe Walker's [samedomain-cookies]. Michal Zalewski, Goodwin's and Joe Walker's [samedomain-cookies]. Michal Zalewski,
Artur Janc, Ryan Sleevi, and Adam Barth provided particularly Artur Janc, Ryan Sleevi, Adam Barth, and Jeff Hodges provided
valuable feedback on this document. particularly valuable feedback on this document.
Authors' Addresses Authors' Addresses
Mike West Mike West
Google, Inc Google, Inc
Email: mkwst@google.com Email: mkwst@google.com
URI: https://mikewest.org/ URI: https://mikewest.org/
Mark Goodwin Mark Goodwin
 End of changes. 65 change blocks. 
160 lines changed or deleted 193 lines changed or added

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