How ads are so relevant: they use HTTP cookies

If you are reading this, then you have encountered that some time you just searched something on Google and it started appearing on the ads. This is all because they use HTTP cookies, so let's start exploring. This read is going to be focused on the anatomy of cookies. Basics 1) What are HTTP cookies? A small data that can be stored on the client's browser, which is sent to the server in every request. 2) What is the use of it? It is used to store auth tokens after login and personalized data like theme, language, etc. Basically, you can store any data that the server can use to tailor the data returned to the client. Most people know about the cookies and use, but there are some important nuance to it, like What are the different purposes of attributes set on the cookies? For example, HttpOnly, Secure, Domain, and SameSite. How cookies behave in cross-site requests. What the heck are third-party cookies? And the biggest question If I search for something on the internet, how does the ad provider come to know, and they start showing me related ads ? Lets start Starting off, we need to understand the attributes set on the cookies. 1. HttpOnly Cookies are key-value pair data, e.g. foo=baar. These cookies are stored on browser and HttpOnly attribute defines if the cookies can be accessed using JavaScript or not. Set this cookie auth_token = sjdsd8hjd7dhbshd on any website just for trial and set the HttpOnly attribute to true. To see cookies using js just type console.log(document.cookies) in the browser console. You will see all other cookies printed (if there are any) but not the cookie that you just set. Now again set the HttpOnly attribute to false, after which you can see it is printed on the console when you re-enter the console.log(document.cookies) command. Conclusion: HttpOnly cookies are sent with requests but cannot be accessed using JavaScript when HttpOnly is set to true. 2. Secure The secure attribute is very simple. When it's true, the cookies are only sent in https not in http connection. If set to false, it will also be sent in an insecure http connection. 3. Domain The domain attribute defines for which domain we are setting the cookies. The cookies can only be set for the same domain you are on right now. Websites are not allowed to set the cookies for other domains. For example,https://dev.to cannot set cookies for https://google.com while staying on https://dev.to. You may see the cookies the browser inspect tool but as soon as you refres it will be gone because browser automatically rejects that. Another important thing: when you set a domain in the cookies, the cookies will be sent to any subdomain of that domain. For e.g. if you set the domain of the cookies to example.com then the cookies will be shared with any subdomain of that domain, like foo.example.com, baar.example.com. But if you do not set the domain attribute, then the browser automatically sets it to the domain, e.g., example.com in that case, the cookies are not shared on the subdomains. 4. SameSite This attribute has 3 possible values: Strict, Lax, None. Lax -> When you are redirected to the website from other website then the cookies will be included in the request. Example. You are on Instagram, and someone posts a link to a product on amazon.com. When you click on the link, the request is made to amazon.com, and the request will contain the cookie of amazon.com. So when you are logged in on amazon.com the cookies will be sent on redirect request from instagram and you can directly make the purchase since you auth cookies are present in the cookies. Strict -> Since we already understood lax strict became simple to understand. When strict is set in the same-site attribute, then any redirect request will not contain the cookies. So although you are logged in on amazon.com, it will again ask you to log in because cookies were not sent in the redirect request as a result of setting strict in the same-site attribute. None -> when same site is set to none, then it does not matter which website you are on; the request will include the cookies. Let's say you are on xyzmovies.com, and it contains an iframe of an ad provider. So any cookies set by ads in that iframe that has sameSite set to none will include the cookies in the request to the ad provider. Did you notice that although we are on different websites, the ads can have access to cookies and use those cookies set by the ad provider? Yes, this is the basis for answer to how ads are relevent to our current search. One more thing to keep in mind that samesite can only be set to none when the connection is https. Browser doesnot allow to set samesite to none on a http connection. Next How do cookies behave in a cross-site request? Let's answer this question. cross-site request means if you are on example.com and you make a request at other domain, lets say abc.com

Apr 5, 2025 - 16:59

How ads are so relevant: they use HTTP cookies

If you are reading this, then you have encountered that some time you just searched something on Google and it started appearing on the ads. This is all because they use HTTP cookies, so let's start exploring. This read is going to be focused on the anatomy of cookies.

Basics

1) What are HTTP cookies?
A small data that can be stored on the client's browser, which is sent to the server in every request.

2) What is the use of it?
It is used to store auth tokens after login and personalized data like theme, language, etc. Basically, you can store any data that the server can use to tailor the data returned to the client.

Most people know about the cookies and use, but there are some important nuance to it, like

What are the different purposes of attributes set on the cookies? For example, HttpOnly, Secure, Domain, and SameSite.
How cookies behave in cross-site requests.
What the heck are third-party cookies?

And the biggest question

If I search for something on the internet, how does the ad provider come to know, and they start showing me related ads ?

Lets start

Starting off, we need to understand the attributes set on the cookies.

1. HttpOnly

Cookies are key-value pair data, e.g. foo=baar. These cookies are stored on browser and HttpOnly attribute defines if the cookies can be accessed using JavaScript or not.

Set this cookie auth_token = sjdsd8hjd7dhbshd on any website just for trial and set the HttpOnly attribute to true. To see cookies using js just type console.log(document.cookies) in the browser console. You will see all other cookies printed (if there are any) but not the cookie that you just set. Now again set the HttpOnly attribute to false, after which you can see it is printed on the console when you re-enter the console.log(document.cookies) command.

Conclusion: HttpOnly cookies are sent with requests but cannot be accessed using JavaScript when HttpOnly is set to true.

2. Secure

The secure attribute is very simple. When it's true, the cookies are only sent in https not in http connection. If set to false, it will also be sent in an insecure http connection.

3. Domain

The domain attribute defines for which domain we are setting the cookies. The cookies can only be set for the same domain you are on right now. Websites are not allowed to set the cookies for other domains. For example,https://dev.to cannot set cookies for https://google.com while staying on https://dev.to. You may see the cookies the browser inspect tool but as soon as you refres it will be gone because browser automatically rejects that.

Another important thing: when you set a domain in the cookies, the cookies will be sent to any subdomain of that domain. For e.g. if you set the domain of the cookies to example.com then the cookies will be shared with any subdomain of that domain, like foo.example.com, baar.example.com. But if you do not set the domain attribute, then the browser automatically sets it to the domain, e.g., example.com in that case, the cookies are not shared on the subdomains.

4. SameSite

This attribute has 3 possible values: Strict, Lax, None.

Lax -> When you are redirected to the website from other website then the cookies will be included in the request.
Example. You are on Instagram, and someone posts a link to a product on amazon.com. When you click on the link, the request is made to amazon.com, and the request will contain the cookie of amazon.com. So when you are logged in on amazon.com the cookies will be sent on redirect request from instagram and you can directly make the purchase since you auth cookies are present in the cookies.

Strict -> Since we already understood lax strict became simple to understand. When strict is set in the same-site attribute, then any redirect request will not contain the cookies. So although you are logged in on amazon.com, it will again ask you to log in because cookies were not sent in the redirect request as a result of setting strict in the same-site attribute.

None -> when same site is set to none, then it does not matter which website you are on; the request will include the cookies. Let's say you are on xyzmovies.com, and it contains an iframe of an ad provider. So any cookies set by ads in that iframe that has sameSite set to none will include the cookies in the request to the ad provider. Did you notice that although we are on different websites, the ads can have access to cookies and use those cookies set by the ad provider? Yes, this is the basis for answer to how ads are relevent to our current search. One more thing to keep in mind that samesite can only be set to none when the connection is https. Browser doesnot allow to set samesite to none on a http connection.

How do cookies behave in a cross-site request? Let's answer this question.

cross-site request means if you are on example.com and you make a request at other domain, lets say abc.com then it is called cross-site request.

When you make corss-site request the cookies associated with that domain (abc.com) will not be included automatically. you need to include the cookies, in fetch api you can do it this way.

fetch("https://abc.com",{
   credentials: 'include',
})

But still it will not work because browser CORS policy block including cookies in a cross-site request unless the cross-site server has these two headers set and remember the allowed origin must be specific, * is not allowed, browser will again block the request if the allowed origin is *.

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.com

Ensure these 2 points when you need to make cross-site request with cookies

The website you are requesting must set the allow credentail headers and the allowed origin must match the origin you are trying to request from.
Your request must set the credentials to 'include'

Now the answering main question.

How does the ad provider come to know your search, and how do they start showing related ads ?

The answer is by using the third-party cookies
Let's take an example of Google Ads. Imagine when you visit some e-commerce site searching for a laptop and that e-commerce site contains the ad from Google. The ad can set cookies on the browser with the SameSite property to None. That means the cookies of that ad provider will be sent no matter the website you are on. When you visit some other website that also contains the ads from the same provider, here it is: Google Ads. Then again, the request to the ad server will be made using the cookies it set earlier, and it will figure out that this same client visited the e-commerce site for buying a laptop, so let's show ads related to laptops.

How to prevent it ?

Simply blocking any third-party cookies on the browser. Some browsers by default block 3rd-party cookies, and in some you need to enable them.

Conclusion

If you are a developer, set the cookies attribute mindfully to prevent cookie-related attacks.
And if you don't want the ads to track you, then block 3rd-party cookies.

I keep posting useful content on twitter. Lets connect

x.com