The HTTP cookie processing algorithm in terms of Same Origin Policy and “effective Top Level Domains (eTLDs)” aka “Public Suffixes”
This document explains the standardized HTTP cookie-setting and cookie-returning algorithms implemented in HTTP clients (e.g., web browsers). Collectively, these algorithms implement what is colloquially known as the “Cookie Same Origin Policy”. These algorithms are embedded within the HTTP State Management (aka “HTTP cookies”) specification [RFC6265]. They can be difficult to extract and unambiguously point to — hopefully this document will help.
Contents:
1. Terminology
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
4. Excerpts from [RFC6265]
5. References
1. Terminology:
- Cookie:
A unit of HTTP state management data, sent by the server to the user agent (UA) as an optional part of HTTP responses. The UA returns cookie(s) to the server on all subsequent requests, modulo various rules (some of which are discussed herein, the full story is given by [RFC6265]). - Cookie Same Origin Policy:
The Same Origin Policy (SOP) is an overall privilege separation notion manifested in various aspects of web clients (e.g., web browsers). In terms of what is sometimes referred to as “the same-origin policy for cookies” (note: that page is somewhat out-of-date), or as the “Cookie Same-origin Policy”, it is comprised of the overall set of algorithms teased apart in this document, and specified in [RFC6265]. See also Section 4, below. - eTLD / effective Top Level Domain:
This is a term closely related to “public suffix”. It is more general than the term “public suffix” — i.e., because it implies that the domain in question ought to be treated effectively as a Top Level Domain (TLD), but it may actually not be an official TLD, nor might it allow for “public” subdomain registrations (as the term “public suffix” specifically implies). - Origin: A {scheme, host, port} tuple of a webapp [RFC6454], also known as a Web Origin.
- Public Suffix:
A “public suffix” is a DNS domain [RFC1034] under which Internet users can directly register names [modulo some policies]. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us [PSL]. Note however, this definition does not adequately address various subtleties in practice (hence, in part, the [DBOUND] effort). Also note that the term “effective TLD (eTLD)” is closely related, and that the domains listed in [eTLD] are a superset of actual IANA-registered TLDs [IANA-TLDs]. - single-label domain name:
A DNS name consisting of a single label, e.g., “org”, “net”, “com”. Note that on various networks, often in enterprise deployments, existence of “local” single-label domains is not uncommon, e.g., “corp”, “www”. See also eTLD and TLD. - subdomain:
A child domain of some given domain [RFC1034]. E.g., foo.example.org is a subdomain of example.org. - superdomain:
The parent domain of some given domain. E.g., example.org is the superdomain of foo.example.org. - TLD / Top-level Domain:
TLDs are those single-label DNS domains directly under the global public DNS root [IANA-TLDs] [RFC1591]. However, not all single-label DNS names are globally-visible TLDs. See also single-label domain name. - UA / User Agent:
A web browser, or other HTTP client implementation, that implements the HTTP State spec [RFC6265], i.e., accepts cookies sent by HTTP servers. - webapp:
A web application, which has both a server-side and client-side instances. The client-side instances, which are emitted by the server-side over HTTP, are effectively mobile code (typically composed of HTML+JavaScript+CSS+etc), and execute within UAs (as “web pages”), and have an origin derived from the server-side’s URI. Note that this also encompasses “apps” that are not general purpose web browsers but that meet the definition of UA.
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
(a) A server-side webapp, whose origin’s host component [RFC6454] (aka domain name) IS NOT a eTLD [eTLD] ( see also “public suffix” [PSL]), can “set cookies” (on UAs) for its own domain name, or for superdomains — unless the targeted superdomain is an eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only that host, or, to that host and all subdomains thereof (depending on server-specified particulars of the cookie itself).
(c) Conversely, a server-side webapp whose origin’s host component IS denoted as a eTLD/”public suffix” (i.e., it appears in [eTLD] or similar compendiums) can set cookies for itself (modulo UA configuration), but its subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD’s cookies to subdomain servers.
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs:
Excerpts from [RFC6265] expressing the specifics underlying the cookie-setting and -returning algorithms, and in which the effects of “public suffixes”/eTLDs are specified, are found in the section following this one. They are referred to (using an “S” prefix) in the following explanations of the algorithms (a), (b), (c), and (d), summarized in the preceding section:
In terms of (a), a server that is NOT a eTLD doing cookie-setting: the 2nd portion of S 4.1.2.3 describes the cookie-setting semantics, step 5 of S 5.3 handles cookie-setting attempts for “public suffixes”, step 6 of S 5.3 defines the determination of the cookie’s applicable domain and its notation in the cookie’s cookie store entry, e.g. setting the host-only-flag. The host-only-flag governs whether the cookie will be returned to the origin server only, or whether it will be returned to the origin server as well as its subdomains.
In terms of (b), a UA returning cookies to non-eTLD servers: S 5.4 governs the construction of the Cookie header for the HTTP request, which depends directly upon the cookie entry’s host-only-flag, and the domain-match algorithm (S 5.1.3).
In terms of (c), a eTLD/”public suffix” webapp doing cookie-setting: the 2nd portion of S 4.1.2.3 describes again applies, and refers directly to S 5.3 in this case. S 5.3 steps 5 and 6 apply and the path through them depends on whether the UA is config’d to reject eTLDs or not. If not, and the domain-attribute is empty, then in step 6 the cookie is stored in the cookie store with its host-only-flag set to true and its domain set to the canonicalized request-host.
In terms of (d), a UA returning cookies to a “public suffix”/eTLD server: step 1 of S 5.4 will gather only such cookies and return them to ONLY the eTLD server, due to the manner that they were recorded in the cookie store.
4. Excerpts from [RFC6265]:
[Note: I’ve included the hierarchy of [RFC6265] section titles in order to provide context.]
4. Server Requirements
4.1. Set-Cookie
4.1.2. Semantics (Non-Normative)
4.1.2.3. The Domain Attribute
https://tools.ietf.org/html/rfc6265#section-4.1.2.3
The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. ... If the server omits the Domain attribute,
the user agent will return the cookie only to the origin server.
...
The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a
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
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes". For example,
some user agents will reject Domain attributes of "com" or "co.uk".
(See Section 5.3 for more information.)
...
5. User Agent Requirements
5.1. Subcomponent Algorithms
5.1.3. Domain Matching
https://tools.ietf.org/html/rfc6265#section-5.1.3
A string domain-matches a given domain string if at least one of the
following conditions hold:
o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to
lower case at this point.)
o All of the following conditions hold:
* The domain string is a suffix of the string.
* The last character of the string that is not included in the
domain string is a %x2E (".") character.
* The string is a host name (i.e., not an IP address).
5.3. Storage Model
https://tools.ietf.org/html/rfc6265#section-5.3
...
5. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized
request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at
5. References:
[DBOUND] https://datatracker.ietf.org/wg/dbound/charter/
[IANA-TLDs] https://www.iana.org/domains/root/db
[eTLD]
The "effective Top Level Domain List (eTLD)
https://publicsuffix.org/list/effective_tld_names.dat
[PSL]
Public Suffix List:
[RFC1034]
DOMAIN NAMES - CONCEPTS AND FACILITIES:
https://tools.ietf.org/html/rfc1034
[RFC1591]
Domain Name System Structure and Delegation:
http://tools.ietf.org/html/rfc1591, see also: https://en.wikipedia.org/wiki/Top-level_domain
[RFC6265]
HTTP State Management Mechanism:
https://tools.ietf.org/html/rfc6265
[RFC6454]
The Web Origin Concept:
https://tools.ietf.org/html/rfc6454
Change Log:
Originally published on: Apr 30, 2015 @ 13:18 PDT, plus there’s been a few minor editorial updates since then, eg I changed the article title in May-2016.