Looking At How Cookies And Domains Interact In ColdFusion

In my previous post on leading dots (.) in Cookie domains, I mentioned that my mental model for how Cookies work leaves something to be desired. Along the same lines, I don't have a solid understanding for when Cookies with explicit / non-explicit Domain attributes are sent to the server. As such, I wanted to run some experiments using different combinations of setting and getting of cookie values in ColdFusion.

In order to start exploring Cookie domain behaviors, I went into my /etc/hosts file locally and defined a series of subdomains that all point back to my localhost:

# Route all of these to localhost for cookie testing.
127.0.0.1 a.com
127.0.0.1 b.a.com
127.0.0.1 c.b.a.com
127.0.0.1 d.c.b.a.com

As you can see, each subdomain builds on top of the one before it. This way, we can (for example) see how a.com cookies interact with b.a.com, and vice-versa.

Then, I created a ColdFusion page (using Lucee CFML) that sets 5 different cookies: one for each of these domains and one more without an explicit domain:

<cfscript>

	cookie[ "a" ] = {
		domain: "a.com",
		value: "a",
		preserveCase: true,
		expires: 1
	};

	cookie[ "b" ] = {
		domain: "b.a.com",
		value: "b",
		preserveCase: true,
		expires: 1
	};

	cookie[ "c" ] = {
		domain: "c.b.a.com",
		value: "c",
		preserveCase: true,
		expires: 1
	};

	cookie[ "d" ] = {
		domain: "d.c.b.a.com",
		value: "d",
		preserveCase: true,
		expires: 1
	};

	// And what if NO DOMAIN is provided at all. Save the SERVER NAME into the value of
	// the no-domain cookie so we can see where it shows up.
	cookie[ "no_domain" ] = {
		value: cgi.server_name,
		preserveCase: true,
		expires: 1
	};

</cfscript>

Now, if we run this ColdFusion page on the domain, c.b.a.com, we can see the Set-Cookie HTTP Headers in the response:

Based on this HTTP response, what we can see is that the browser allows cookies to be set by any domain that is currently represented in the URL:

• a.com - Set because it is a suffix of c.b.a.com.
• b.a.com - Set because it is a suffix of c.b.a.com.
• c.b.a.com - Set because it is a suffix of c.b.a.com.
• d.c.b.a.com - Not set because it is not represented in the URL.

Now that we have our HTTP Cookies set, it's time to try and send them back to the server. For this, I created another ColdFusion page that dumps-out the cookie scope. And, provides convenient links for jumping between the various subdomains:

<cfoutput>

	<ul>
		<li><a href="http://a.com:#cgi.server_port##cgi.script_name#">a.com</a>
		<li><a href="http://b.a.com:#cgi.server_port##cgi.script_name#">b.a.com</a>
		<li><a href="http://c.b.a.com:#cgi.server_port##cgi.script_name#">c.b.a.com</a>
		<li><a href="http://d.c.b.a.com:#cgi.server_port##cgi.script_name#">d.c.b.a.com</a>
	</ul>

	<cfdump var="#cgi.server_name#" label="Server" />
	<cfdump var="#cookie#" label="Cookie Scope" />

</cfoutput>

If we access this ColdFusion page from a.com, we get the following:

As you can see, only the one cookie associated with the a.com domain is made available to our ColdFusion app. We do not get access to any of the larger subdomains on the same registrable domain.

If we access this ColdFusion page from b.a.com, we get the following:

As you can see, we now get the cookie associated with the subsumed subdomain, a.com, as well as the cookie associated with the current b.a.com domain.

If we access this ColdFusion page from c.b.a.com, we get the following:

As you can see, we now get the cookies associated with all the subsumed domains represented in the URL (a.com and b.a.com). And, we also get the two cookies associated with current host, c.b.a.com. Note that this includes the one cookie that was set with no explicit domain - this comes into play in the next example.

Now, if we access this ColdFusion page from d.c.b.a.com, we get the following:

As you can see, we now get access to the cookies associated with all of the subsumed subdomains represented in the URL (a.com, b.a.com, and c.b.a.com); however, we do not get access to the one cookie on c.b.a.com that was defined without an explicit domain. By defining a cookie without a domain, you make it more restrictive as it is constrained to the implied domain only.

ASIDE: Note that there is no d.c.b.a.com cookie as our Set-Cookie header was rejected above when we tried to set it from the smaller subdomain, c.b.a.com.

Being able to see this cookie behavior on iterative subdomains was super helpful. Basically, if it's in the URL (either as the full host or a subsumed subdomain suffix), you get the cookie. The exception being that if no explicit Domain was provided, you only get it on the original defining host.

ASIDE: None of this takes into account other cookie settings like Secure and SameSite - this was only intended to explore the interplay between cookie Domains and the current host.

Want to use code from this post? Check out the license.

Short link: https://bennadel.com/go/4346