466

Due to weird domain/subdomain cookie issues that I'm getting, I'd like to know how browsers handle cookies. If they do it in different ways, it would also be nice to know the differences.

In other words - when a browser receives a cookie, that cookie MAY have a domain and a path attached to it. Or not, in which case the browser probably substitutes some defaults for them. Question 1: what are they?

Later, when the browser is about to make a request, it checks its cookies and filters out the ones it should send for that request. It does so by matching them against the requests path and domain. Question 2: what are the matching rules?

Added:

The reason I'm asking this is because I'm interested in some edge cases. Like:

  • Will a cookie for .example.com be available for www.example.com?
  • Will a cookie for .example.com be available for example.com?
  • Will a cookie for example.com be available for www.example.com?
  • Will a cookie for example.com be available for anotherexample.com?
  • Will www.example.com be able to set cookie for example.com?
  • Will www.example.com be able to set cookie for www2.example.com?
  • Will www.example.com be able to set cookie for .com?
  • Etc.

Added 2:

Also, could someone suggest how I should set a cookie so that:

  • It can be set by either www.example.com or example.com;
  • It is accessible by both www.example.com and example.com.
Vilx-
  • 104,512
  • 87
  • 279
  • 422

9 Answers9

430

Although there is the RFC 2965 (Set-Cookie2, had already obsoleted RFC 2109) that should define the cookie nowadays, most browsers don’t fully support that but just comply to the original specification by Netscape.

There is a distinction between the Domain attribute value and the effective domain: the former is taken from the Set-Cookie header field and the latter is the interpretation of that attribute value. According to the RFC 2965, the following should apply:

  • If the Set-Cookie header field does not have a Domain attribute, the effective domain is the domain of the request.
  • If there is a Domain attribute present, its value will be used as effective domain (if the value does not start with a . it will be added by the client).

Having the effective domain it must also domain-match the current requested domain for being set; otherwise the cookie will be revised. The same rule applies for choosing the cookies to be sent in a request.

Mapping this knowledge onto your questions, the following should apply:

  • Cookie with Domain=.example.com will be available for www.example.com
  • Cookie with Domain=.example.com will be available for example.com
  • Cookie with Domain=example.com will be converted to .example.com and thus will also be available for www.example.com
  • Cookie with Domain=example.com will not be available for anotherexample.com
  • www.example.com will be able to set cookie for example.com
  • www.example.com will not be able to set cookie for www2.example.com
  • www.example.com will not be able to set cookie for .com

And to set and read a cookie for/by www.example.com and example.com, set it for .www.example.com and .example.com respectively. But the first (.www.example.com) will only be accessible for other domains below that domain (e.g. foo.www.example.com or bar.www.example.com) where .example.com can also be accessed by any other domain below example.com (e.g. foo.example.com or bar.example.com).

Community
  • 1
  • 1
Gumbo
  • 643,351
  • 109
  • 780
  • 844
  • @Gumbo So a.b.c.example.com can access the cookie with domain c.example.com? – Pacerier Jul 18 '12 at 05:09
  • 2
    *very* late follow up question to this one. My own experience and this: http://webmasters.stackexchange.com/questions/55790/setting-cookies-only-on-the-naked-domain suggest that the domain of example.com will not be available to www.example.com, but this example suggests otherwise. Is this example wrong, or am I (quite possible) misunderstanding. Sorry for thread necromancy but wanted to make sure this excellent answer was 100% accurate for future confused newbies like me :) – errah Apr 09 '14 at 02:43
  • 7
    this answer is a little outdated; see [my answer](http://stackoverflow.com/a/30676300/2158288) below. – ZhongYu Jun 05 '15 at 22:11
  • 1
    why not setting for example.com be available for www.example.com? (as it's a "www" sub of example.com? – Nabeel Khan Jan 26 '16 at 04:57
  • Set-Cookie2 is itself obsolete. Continue to use Set-Cookie. – joeforker Aug 28 '18 at 12:47
  • thanks for pointing out the domain-match algorithm. After reading through it, I find it very easy to verify the examples listed in your answer. – torez233 Jun 25 '21 at 05:41
  • Thanks, I was facing an issue where browser always adds . to domain and then cookies become accessible in subdomains , changing to www.example.com fixed that :) – Madian Malfi Aug 12 '22 at 08:22
164

The previous answers are a little outdated.

RFC 6265 was published in 2011, based on the browser consensus at that time. Since then, there has been some complication with public suffix domains. I've written an article explaining the current situation - http://bayou.io/draft/cookie.domain.html

To summarize, rules to follow regarding cookie domain:

  • The origin domain of a cookie is the domain of the originating request.

  • If the origin domain is an IP, the cookie's domain attribute must not be set.

  • If a cookie's domain attribute is not set, the cookie is only applicable to its origin domain.

  • If a cookie's domain attribute is set,

    • the cookie is applicable to that domain and all its subdomains;
    • the cookie's domain must be the same as, or a parent of, the origin domain
    • the cookie's domain must not be a TLD, a public suffix, or a parent of a public suffix.

It can be derived that a cookie is always applicable to its origin domain.

The cookie domain should not have a leading dot, as in .foo.com - simply use foo.com

As an example,

  • x.y.z.com can set a cookie domain to itself or parents - x.y.z.com, y.z.com, z.com. But not com, which is a public suffix.
  • a cookie with domain=y.z.com is applicable to y.z.com, x.y.z.com, a.x.y.z.com etc.

Examples of public suffixes - com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com

Community
  • 1
  • 1
ZhongYu
  • 19,446
  • 5
  • 33
  • 61
  • do all browsers follow RFC 6265? – roelleor Jul 09 '15 at 07:47
  • 7
    @roelleor - it's the other way around. rfc6265 was written to summarize how cookies were actually handled in practice :) yes, the rfc is a pretty accurate reflection of how major browsers behave. my recent tests on browsers confirmed that. although, they may differ on corner cases involving public suffixes. – ZhongYu Jul 09 '15 at 14:07
  • 2
    What are the consequences of a leading dot? – UpTheCreek Nov 18 '15 at 11:58
  • 3
    @UpTheCreek - according to rfc6265, leading dot should be ignored by client – ZhongYu Dec 08 '15 at 21:05
  • 3
    Isn't it strange that `x.y.z.com` can set a cookie to `z.com` ? – Royi Namir Mar 18 '19 at 07:48
  • 3
    So if x.y.z.com can set a cookie to y.z.com, and a cookie with domain y.z.com is applicable to w.y.z.com... Does that mean that **x.y.z.com can set a cookie to w.y.z.com**? – Ioanna May 07 '19 at 03:38
  • 1
    All the list of public suffix for which cookies cannot be set : https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat – Number945 Dec 12 '20 at 18:24
  • 2
    @Ioanna if you are talking the in the response from x.y.z.com, the domain attribute value for the cookie is w.y.z.com, then I think the answer is no. x.y.z.com cannot directly set the cookie whose domain to be w.y.z.com, as x.y.z.com does not domain-match the w.y.z.com, as latter is not a suffix of the former. However, I think x.y.z.com can indirectly set a cookie for w.y.z.com, by setting the cookie for y.z.com and that cookie will be sent to w.y.z.com as well, assuming y.z.com is not a public suffix – torez233 Jun 25 '21 at 05:50
  • "the cookie's domain must be the same as, or a parent of, the origin domain" this is key. From [rfc6265](https://datatracker.ietf.org/doc/html/rfc6265#section-5.3): "If the canonicalized request-host does not domain-match the domain-attribute: Ignore the cookie entirely and abort these steps." (request-host is the server sending the cookie, and domain-match means it equals to or ends with the string). – Alex Jun 25 '22 at 21:46
15

I tested all the cases in the latest Chrome, Firefox, Safari in 2019.

Response to Added:

  • Will a cookie for .example.com be available for www.example.com? YES
  • Will a cookie for .example.com be available for example.com? YES
  • Will a cookie for example.com be available for www.example.com? NO, Domain without wildcard only matches itself.
  • Will a cookie for example.com be available for anotherexample.com? NO
  • Will www.example.com be able to set cookie for example.com? NO, it will be able to set cookie for '.example.com', but not 'example.com'.
  • Will www.example.com be able to set cookie for www2.example.com? NO. But it can set cookie for .example.com, which www2.example.com can access.
  • Will www.example.com be able to set cookie for .com? NO
xiaoke
  • 3,272
  • 2
  • 17
  • 20
  • 2
    The leading domain in cookie domain is a misnomer. And your answers directly contradicting with Mozilla's documentation on Cookie: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie see the Domain section: `Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored.` – Devy Jun 25 '20 at 16:20
10

For an extensive coverage review the contents of RFC2965. Of course that doesn't necessarily mean that all browsers behave exactly the same way.

However in general the rule for default Path if none specified in the cookie is the path in the URL from which the Set-Cookie header arrived. Similarly the default for the Domain is the full host name in the URL from which the Set-Cookie arrived.

Matching rules for the domain require the cookie Domain to match the host to which the request is being made. The cookie can specify a wider domain match by include *. in the domain attribute of Set-Cookie (this one area that browsers may vary). Matching the path (assuming the domain matches) is a simple matter that the requested path must be inside the path specified on the cookie. Typically session cookies are set with path=/ or path=/applicationName/ so the cookie is available to all requests into the application.

__Response to Added:__
  • Will a cookie for .example.com be available for www.example.com? Yes
  • Will a cookie for .example.com be available for example.com? Don't Know
  • Will a cookie for example.com be available for www.example.com? Shouldn't but... *
  • Will a cookie for example.com be available for anotherexample.com? No
  • Will www.example.com be able to set cookie for example.com? Yes
  • Will www.example.com be able to set cookie for www2.example.com? No (Except via .example.com)
  • Will www.example.com be able to set cookie for .com? No (Can't set a cookie this high up the namespace nor can you set one for something like .co.uk).

* I'm unable to test this right now but I have an inkling that at least IE7/6 would treat the path example.com as if it were .example.com.

Community
  • 1
  • 1
AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • I've added some interesting edge cases in my question. Could you maybe commend something on that? – Vilx- Jun 30 '09 at 10:58
9

The last (third to be exactly) RFC for this issue is RFC-6265 (Obsoletes RFC-2965 that in turn obsoletes RFC-2109).

According to it if the server omits the Domain attribute, the user agent will return the cookie only to the origin server (the server on which a given resource resides). But it's also warning that some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name (For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well).

When the Domain attribute have been specified, it will be treated as complete domain name (if there is the leading dot in attribute it will be ignored). Server should match the domain specified in attribute (have exactly the same domain name or to be a subdomain of it) to get this cookie. More accurately it specified here.

So, for example:

  • cookie attribute Domain=.example.com is equivalent to Domain=example.com
  • cookies with such Domain attributes will be available for example.com and www.example.com
  • cookies with such Domain attributes will be not available for another-example.com
  • specifying cookie attribute like Domain=www.example.com will close the way for www4.example.com

PS: trailing comma in Domain attribute will cause the user agent to ignore the attribute =(

Community
  • 1
  • 1
Victor Akimov
  • 531
  • 4
  • 9
5

The RFCs are known not to reflect reality.

Better check draft-ietf-httpstate-cookie, work in progress.

Community
  • 1
  • 1
Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
3

There are rules that determine whether a browser will accept the Set-header response header (server-side cookie writing), a slightly different rules/interpretations for cookie set using Javascript (I haven't tested VBScript).

Then there are rules that determine whether the browser will send a cookie along with the page request.

There are differences between the major browser engines how domain matches are handled, and how parameters in path values are interpreted. You can find some empirical evidence in the article How Different Browsers Handle Cookies Differently

Gert-Jan Strik
  • 31
  • 1
2

Will www.example.com be able to set cookie for .com?

No, but example.com.fr may be able to set a cookie for example2.com.fr. Firefox protects against this by maintaining a list of TLDs: http://securitylabs.websense.com/content/Blogs/3108.aspx

Apparently Internet Explorer doesn't allow two-letter domains to set cookies, which I suppose explains why o2.ie simply redirects to o2online.ie. I'd often wondered that.

TRiG
  • 10,148
  • 7
  • 57
  • 107
  • 1
    "com.fr" is konwn as "public suffix". cookie domain cannot be public suffix. see rfc 6265 and https://publicsuffix.org – ZhongYu Jun 05 '15 at 21:01
  • Yes, there's a solution, but it's an exceedingly messy one. This sort of labelling should be baked into the DNS, not done on an ad hoc basis separately. – TRiG Jun 06 '15 at 03:17
  • True, and maybe you are referring to "dbound". But that may create more problems; like, posing a challenge for http client implementations. – ZhongYu Jun 06 '15 at 03:24
  • It would be useful if this information were exposed in some way from the browser to javascript. Otherwise, it's impossible to programmatically determine whether you can set a cookie on a certain level of domain. You can't check that list with every call after all! – Dtipson Nov 30 '16 at 04:26
2

I was surprised to read section 3.3.2 about rejecting cookies:

https://www.rfc-editor.org/rfc/rfc2965

That says that a browser should reject a cookie from x.y.z.com with domain .z.com, because 'x.y' contains a dot. So, unless I am misinterpreting the RFC and/or the questions above, there could be questions added:

Will a cookie for .example.com be available for www.yyy.example.com? No.

Will a cookie set by origin server www.yyy.example.com, with domain .example.com, have it's value sent by the user agent to xxx.example.com? No.

Community
  • 1
  • 1
user100034
  • 29
  • 3
  • 2
    that rfc is outdated. new rfc 6265, based on browser consensus, allows cookie with `z.com` to be applied to `z.com` and *all* subdomains. – ZhongYu Jun 05 '15 at 20:58