Can subdomain.example.com set a cookie that can be read by example.com?
Solution 1:
Quoting from the same RFC2109 you read:
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would be accepted.
So subdomain.example.com
can set a cookie for .example.com
. So far so good.
The following rules apply to choosing applicable cookie-values from among all the cookies the user agent has. Domain Selection The origin server's fully-qualified host name must domain-match the Domain attribute of the cookie
So do we have a domain-match?
* A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)
But now example.com
wouldn't domain-match .example.com
according to the definition. But www.example.com
(or any other "non-empty name" in the domain) would. This RFC is in theory obsoleted by RFC2965, which dictated things about forcing a leading dot for domains on Set-Cookie2
operations.
More important, as noted by @Tony, is the real world. For a glimpse into what actual user agents are doing, see
Firefox 3's nsCookieService.cpp
and
Chrome's cookie_monster.cc
For perspective into what actual sites are doing, try playing with wget
using --save-cookies
, --load-cookies
, and --debug
to see what's going on.
You'll likely find that in fact most sites are using some combination of Set-Cookie
from the older RFC spec with "Host" values, implicitly without a leading dot (as twitter.com does) or setting Domain values (with a leading dot) and redirecting to a server like www.example.com
(as google.com does).
Solution 2:
If the browser implements RFC 6265, which any modern browser should be doing at this point, then a cookie set for .example.com
will have the leading dot ignored (section 5.2.3), and the cookie will then be sent to the naked domain and to all subdomains.
Don't rely on this behavior if you have significant traffic from older browsers; this RFC only dates to 2011.
Solution 3:
It should not be possible. However, as you said, since this isn't a widely documented standard, it depends on what piece of software you're using.
Most modern browsers adhere to a defined "web security model". The model effectively governs the behavior of browsers with regards to security, on things like cookies (specifically how they will be sent back to any given website). The model also has the rule that "browsers don't send cookies to domain names that didn't set them."
That being said, domain.com should be able to set cookies for js.domain.com. js.domain.com, however, can only set cookies for itself. But this is all depending on what browser you're using.