{"id":52418,"date":"2013-10-08T09:10:35","date_gmt":"2013-10-08T07:10:35","guid":{"rendered":"https:\/\/www.humanlevel.com\/sin-categorizar\/que-son-y-como-funcionan-las-cookies.html"},"modified":"2021-03-04T08:43:00","modified_gmt":"2021-03-04T07:43:00","slug":"what-are-cookies-and-how-do-they-work","status":"publish","type":"post","link":"https:\/\/www.humanlevel.com\/en\/blog\/seo\/what-are-cookies-and-how-do-they-work","title":{"rendered":"What are cookies and how do they work?"},"content":{"rendered":"

What are cookies and how do they work?<\/h2>\n

\"cookie-monster\"A cookie or computer cookie<\/strong> is a small file with information that is stored in the user’s browser when visiting a website and in which the user’s settings and preferences or the status of the browsing session, such as whether or not the user is logged in, or the products that have been added to the shopping cart, are usually stored.<\/p>\n\n

Lately there has been a lot of talk about cookies<\/strong> due to the advent of the anti-cookie law<\/a>, but few people really understand what they are and how they work<\/strong>. Let’s see what they consist of:<\/p>\n

The files that make up the websites travel through the networks encapsulated within packets of information using the HTTP<\/strong> protocol (Hypertext Transfer Protocol). This protocol is said to be stateless<\/strong> because it has no way of storing state between requests. Some examples of statuses can be: being logged in, if it is not the first visit to the site, having a product in the shopping cart, etc. One of the ways to maintain state<\/strong> and, therefore, to allow the content of the same URL<\/strong> to change according to the user’s actions<\/strong>, are cookies<\/strong>.<\/p>\n

A cookie consists of a key that gives it a name and an associated value<\/strong>, which can be created, modified or deleted both on the client and on the server<\/strong> and which, once created, is sent in each HTTP request, for each file<\/strong>, as a parameter of this protocol. The name cookies <\/strong>is derived from the computer term magic cookie, <\/strong>which defines information that is sent and returned the same on every request.<\/p>\n

For example, we can have a cookie whose key is “cart” with the value “12345”, which indicates that the web has to show the cart with identifier “12345”. This cart will contain the products chosen by the user for later purchase.<\/p>\n

How do cookies work?<\/h2>\n

Cookies can be persistent or non-persistent<\/strong>. They are persistent, if they have an expiration time<\/strong> and if they do not, they are deleted when the browser is closed<\/strong>. Non-persistent cookies are those used to keep the<\/strong> user’ s session open<\/strong>, since the server knows from the cookie’s identifier to which user each open session belongs in memory.
\nIn order to prevent any page from being able to recover the state that the user had on a different website, cookies are always associated with a domain<\/strong> and can only be created, modified or deleted if they belong to the same domain or to the top-level subdomain<\/strong>. For example, if we are visiting a.b.c.com code will be able to write cookies in a.b.c.com and b.c.com, but not in c.com. Another security restriction is that you can never create cookies belonging to a TLD<\/a><\/strong> (e.g. .com), this type of cookies are called supercookies<\/strong>. As an additional security measure, we can create cookies so that they can only be read from a specific URL.<\/p>\n

Let us now look at a graphic example of what happens when cookies are created on the client and on the server:<\/p>\n

\"Cookies<\/a><\/p>\n

In the example above all cookies belong to the domain www.humanlevel.com, but what happens if we include in www.humanlevel.com a JavaScript that links from another domain (e.g. googleads.g.doubleclick.net)?<\/p>\n

What happens is that when executed in the browser, the JavaScript can create, modify and read cookies from our domain, so in the example above, the external JavaScript would have access to our cookies example1 and example2 and could forward them to their servers through a AJAX<\/a> cross request<\/strong>. That’s why, as I mentioned in another post when I talked about
\nXSS attacks<\/strong>
\n<\/a>attacks, to improve the security of session cookies, it is recommended to always mark them as Httponly<\/strong>, so that they cannot be read by an external JavaScript. In addition, if we mark them as Secure<\/strong> and use HTTPS<\/strong> they will be encrypted.<\/p>\n

However, when the script is generated on the googleads.g.doubleclick.net server, we are not on our domain, but on googleads.g.doubleclick.net and therefore can only create cookies for that domain, but they still reach our browser and are saved. This is called third-party cookies<\/strong>, as they are introduced when you visit our website but do not belong to our domain<\/strong>. In this way, if we then visit another page that use the same JavaScript<\/strong>or other JavaScript from another domain of the same company<\/strong> that sends cross AJAX requests to googleads.g.doubleclick.net, it will be able to retrieve the googleads.g.doubleclick.net cookie from the server side. This cookie will have an identifier<\/strong> that will be used to retrieve the information captured from the user in order to be able to maintain status between different domains<\/strong>. One of the most used applications of this technique is to display advertisements of the pages we have visited.<\/p>\n

Let’s see another graphic example of how this happens:<\/p>\n

\"cookies2\"<\/p>\n

At the time of the first request, the server can read the URL from which the request comes from the HTTP_REFERER parameter of the HTTP header or, once the JavaScript is executed on the client, send this information to itself. In this way, for each website visited by the user, the Adsense server stores the history associated with the NID cookie identifier. Therefore, if the website you had previously visited had Adwords campaigns, your ads will appear<\/strong> on the website you are visiting at that moment.<\/p>\n

As if all this were not already complicated enough, we also have the so-called zombie cookies<\/strong>, which are created again after deleting them, because some scripts regenerate them from time to time.<\/p>\n

All this makes the implementation of the anticookies law quite complex to carry out and it is necessary to develop a specific solution for each website.<\/p>\n

Additional references<\/h2>\n