How cookies are handled by the Browser?

Recommended to first go through my earlier articles

How the browser renders the website page? — https://pandurangpatil.medium.com/how-browser-renders-the-website-efe65ba9dc26

How does the HTTP protocol work? — https://pandurangpatil.medium.com/how-does-http-protocol-work-426b1a4158f3

What’s the purpose of the HTTP Cookie?

As I explained in my earlier articles above, HTTP is a stateless protocol. In order to facilitate this state between Browser and Server HTTP Cookie got introduced. HTTP Cookie facilitates an inherent mechanism to exchange this state between server and Browser. It’s a layer on top of the HTTP protocol with the use of the “set-cookie” response header and “cookie” request header (to understand the request and response header refer).

One of the common use cases of Cookie is to identify the same user between multiple HTTP requests originating from the same Browser. For which There has to be an exchange of unique identifier token between server and Browser. Whenever the server wants to identify the same user, the server will try to read the incoming Cookie token from the “cookie” request header. If it doesn’t find it, the server will create a new unique token, saves it on the server-side as well as send it to the Browser using the “set-cookie” response header. The browser will save this Cookie on the user’s browser storage mapped to the server domain or its parent domain of the server domain (e.g. www.facebook.com). And it will send this cookie back to the Server every time (no matter whether an HTTP request is being made from the current page opened from the same domain or any other domain) whenever the browser makes a request to the same domain ( e.g. www.facebook.com). With third-party cookies being blocked this behavior is going to get changed and Browser will only allow Cookies to be saved and sent only against the HTTP requests made to the original server domain of the page. (more on this in the next article)

Let’s understand the structure of the Domain, parent domain, & subdomains.

Understanding domain name structure properly is required to understand how cookies are mapped to the domain. In turn how cookies are accessed with respect to the given domain.

When we buy any domain like agnie.net or ugaoo.com it is called a root domain (more examples are google.com, faceboo.com, carscan.ai, etc). However, the root domain is rarely used to point directly to the site (there will be some exceptions, in recent days I came across some eCommerce sites directly pointing root domains to their site). The popular subdomain i.e. www is being used by the majority of the sites to point to their main site. The owner of the root domain can create any subdomain using DNS zone files given by their domain service provider.

So root domain owners can create subdomains e.g. www.ugaoo.com, dev.ugaoo.com, etc. In this example, “ugaoo.com” will be the parent domain of “www.ugaoo.com” and “dev.ugaoo.com” in reverse “www.ugaoo.com” & “dev.ugaoo.com” are subdomains of “ugaoo.com”.

How HTTP cookies are handled from the Server?

There are two ways HTTP cookies can be created on the browser from the Server-side and through Javascript running on Browser itself. In this section, we will first focus only on the Server-side mechanism.

How Cookies are created from the Server?

Cookies can be created as well as accessed from the server when any kind of HTTP request is made to the server. When I say any kind of request I literally mean any kind of HTTP request. That includes the URL you hit in your address bar of the browser to resource URL requests made by the browser to fetch the image, javascript, font, & CSS while processing the HTML page.

With this mechanism, the Server can ask Browser to create a cookie by sending a “set-cookie” response header. While we can create the cookies from the server-side, it allows the server to create cookies against the same domain to which the browser had made a request including its parent domain (assuming the request is made to the “www.facebook.com” server, it can set the cookie against “www.facebook.com”, “facebook.com” or “.facebook.com”. However, it cannot set the cookie against “staging.facebook.com” or any other subdomains of “facebook.com”). If the server tries to set the cookie against a domain other than the requested domain from the Browser. The browser simply rejects and doesn’t create the cookie for that domain. We will discuss the structure of the cookie in the below section. (if the requested URL is https://www.facebook.com/tracker then, in this case, the requested domain will be “www.facebook.com”. It can set cookies mapped to “www.facebook.com”, “facebook.com” or “.facebook.com” but cannot set cookies against “www.google.com” or for that matter against the current page URL domain.)

Let’s understand the structure of the HTTP Cookie

The basic structure of the HTTP cookie has only two parts cookie name and its value a pair of key value. There are other attributes attached to this key-value pair that facilitate how this cookie will be accessible either on a browser (through Javascript) or while sending it to the server.

Following attributes are used while creating the cookie

Name — name of the cookie that could be any string without special characters. (Basic and required attribute)

Value — Value of the cookie (basic and required attribute)

Domain — Domain of the cookie. If this attribute is not configured while creating the cookie. It is inferred based on the situation. If cookie is being created through “set-cookie” response header from Server without domain. The cookie will be created and mapped against the requested URL domain. If cookies cannot be set against any other domain apart from the requested domain. Then what’s the purpose of this option given at the time of the creation of the cookie? It has been given to possibly create the cookie against the parent domain or make it available across the subdomain of the parent domain. (when you create the cookie with the parent domain prefixed with “.” e.g. “.facebook.com”, that cookie will be accessible across all the subdomains of “facebook.com”)

Path — This attribute asks the browser to provide access to this cookie only for this path of the URL and its subsequent child paths.

E.g. “/user” if this path is being set while creating the cookie. This cookie will be accessible to the server when the request URL path starts with “/user” e.g. “https://www.facebook.com/user” it is also accessible to the child paths e.g. “https://www.facebook.com/user/a234-sdfb/”. If you want the given cookie to be accessible for any URL path then you need to set this path to “/”.

If you don’t set this path attribute while creating the cookie, the browser will assume the URL path of the request. E.g. if the cookie is getting created while making this request “https://www.facebook.com/session” then the path of this cookie will be set to “/session”.

Expires — This attribute singles browser to set the lifetime of this cookie. With this attribute, you are supposed to set DateTime for the expiry of the cookie. The browser will store this cookie till the expiry DateTime is configured for this cookie.

If you don’t set this attribute, it will be treated as a session cookie. That means the browser will delete this cookie once the user exit the Browser (Closing the tab or one window will not end the session. It will end only when all the windows of the browser are closed.)

HttpOnly — This attribute indicates to the browser to send this cookie along with HTTP requests made to the server. But if you try to access this cookie on Browser through Javascript, it will not be accessible. If you don’t set this attribute then it will be sent along with an HTTP request to the server as well as it will be accessible on the browser through Javascript.

Secure — This attribute indicates to the browser to send this cookie to the server only when HTTPS requests are made to the server.

SameSite — This attribute specifies whether to send this cookie along with HTTP requests apart from the current page URL domain. That means if a user is browsing www.ugaoo.com and the browser already has a cookie created against www.facebook.com but that is set with “SameSite” attribute with either “Strict” or “Lax” then don’t send this cookie while making any HTTP requests made to “www.facebook.com” to fetch any resources.

SameParty — This attribute has been introduced in the wake of third-party cookies getting disabled. This is to facilitate certain functionalities (like single sign-on) which rely on sharing cookies across domains of an organization. It is still evolving functionality, refer to this article for more details.

For more detailed information about the different attributes of the cookie refer

Accessibility of the cookie from the server

In the above section, we discussed how cookies are created from Server and while creating the cookies what all attributes can be attached, which will define the accessibility of the given cookie.

Let’s understand how and when these cookies are being sent to the server and in which format. Whenever a browser makes an HTTP request to the server, it will find all the cookies mapped to the given request URL based on domain, expiry, path, secure, HttpOnly, SameSite & SameParty attributes of the cookie. Creates a “;” separated string of key=value tokens from those list of cookies and sends this string through the HTTP request header “cookie” (refer to my earlier article to understand the request header). Refer above screenshot of the actual request from the dev tools panel of Chrome. Server-side technologies facilitate access to these cookies to read them from the request header.

Can we create the cookie through Javascript on the Browser side or access it?

Yes. We can create the cookie through Javascript on the browser-side as well as access the cookies through Javascript.

However, this cookie can be created only against the current page domain and its parent domain. No matter whether the Javascript code is served from the same domain as that of the page or any other domain. You cannot create an HttpOnly cookie from Javascript.

Similarly one can read the cookies mapped to the current page domain through Javascript along with other restrictions that we discussed above against each attribute of the cookie.

Third-party cookies are created only using the serer-side mechanism. Which is what gets disabled from the browser side. (more on this in the next article)