SameSite Cookie Attribute
This blog explores SameSite cookies, delving into the concept of Lax and Strict cookie value. However, before we dive into the intricacies of SameSite cookies and their properties, let’s first establish a fundamental understanding of what a cookie is.
Is this the cookie we’re referring to?
Indeed, we shall discuss cookies in the context of websites in this blog.
What is a web cookie?
Imagine you’re at a snack shop, and the shopkeeper gives you a small sticker when you enter. This sticker has a code that the shopkeeper can recognize.
Every time you come back to the shop, the shopkeeper looks at the sticker to remember your preferences, like whether you like sweet or salty snacks. This way, the shop can give you the snacks you enjoy without you having to remind them every time.
On the web, a “cookie” is like that sticker. It’s a small piece of information that websites give to your browser. When you revisit the website, it checks the cookie to remember things about your previous visits, so the site can show you things you’re interested in.
In technical terms, A cookie is a little piece of information that is kept in the browser and is used to store state and other data that a website need in order to function. A cookie is a little text file that websites place on a user’s machine. The data it contains circulates between the browser and the website.
Web cookies can be categorised primarily into two groups by party:
- First-party cookies: First-party cookies enable websites to collect analytics data and save user preferences to provide a more customised browsing experience. The visited website or domain stores these cookies, which allow information like login credentials to be kept. This in turn makes it easier to log in and make purchases when a user returns to the website, which is very helpful for e-commerce platforms.
2. Third-Party cookies: A third-party cookie refers to a cookie that is placed on a user’s device, be it a computer, cellphone, or tablet, by a website originating from a domain different from the one the user is actively visiting. These cookies are predominantly employed in the realm of online advertising, where they diligently track a user’s browsing history and activities. The primary objective is to curate personalized ads for products and services.
Imagine you visit a bakery website and they give you a cookie (not the yummy kind!). This cookie remembers you and what kind of bread you like (first-party cookie).
Later, you visit a game website. But wait, there’s also a bakery cookie there! This is a third-party cookie. It followed you from the bakery to show you ads for bread while you play games. Sneaky!
The same cookie can be your friend on one site (remembering your preferences) and a follower on another (showing you ads).
Here’s why this happens:
Pictures travel: Sometimes, websites borrow pictures from other sites. If you’ve visited the picture’s original site, your first-party cookie might accidentally travel with it, even though it’s not really needed on the new site. This is like the bakery cookie going to the game website even though they don’t sell games.
Sharing sessions: Sometimes, websites embed things like YouTube videos. If you’re already signed in to YouTube, its cookie helps you interact with the video without needing to sign in again. This is like the YouTube cookie letting you “watch later” on a different website.
This openness of the web is great for sharing content, but it can also be risky:
Tricking your browser: Bad websites can trick your browser into sending your cookies (like from your blog) to them, even if you didn’t click anything. This could let them do bad things on your blog, like deleting your posts! It’s like a bad guy tricking you into giving them your bakery cookie so they can steal your bread.
The web traditionally operates with an open-by-default culture, enabling widespread content creation and application development. However, this openness introduces security and privacy challenges. Cross-Site Request Forgery (CSRF) attacks exploit the default behavior where cookies accompany any request to a specific origin, regardless of the initiator.
To address these concerns, developers can explicitly communicate their intent with a cookie by configuring the appropriate SameSite attribute.
SameSite cookie attribute
A browser uses SameSite to control how it handles cookies. Determining whether cookies from the website you’re on (first-party) or from another site (third-party) are permitted or restricted is comparable being a digital bouncer. It guarantees the privacy and security of the online experience.
On the website, there are two options available when a establishing a SameSite cookie value: Strict and Lax.
SameSite=Strict cookies
In the context of cookies, “Strict” signifies that the browser transmits the cookie exclusively for requests from the same site, meaning those initiated by the site that initially set the cookie. In case a request originates from a distinct domain or scheme (even if it shares the same domain), cookies marked with the SameSite=Strict attribute will not be sent.
SameSite=Strict cookies are sent in the following scenarios:You enter the URL into the address bar and directly navigate to a site.
You refresh the page using the browser.
You click on a link (<a>) to a page within the same site.
You embed an iframe hosted on the same site (sharing the same domain and scheme).
You initiate an AJAX/fetch request within the same site using JavaScript.
However, SameSite=Strict cookies are not sent in the following cases:
Clicking on a link (<a>) to your site from a different domain; cookies won’t be sent during the initial page load.
A form embedded on another site sends data to your website; Strict cookies won’t be included in the request.
A site from another domain makes an AJAX/fetch request using JavaScript to your site; Strict cookies won’t be included.
Your site is embedded in an iframe on a site hosted on a different domain; your site won’t receive any Strict cookies.
An image on your website is directly linked in the src attribute of an <img> from another site.
Utilizing SameSite=Strict offers robust protection against Cross-Site Request Forgery (CSRF) attacks. In a CSRF attack, the assailant depends on the victim being logged into the website, allowing them to execute actions on behalf of the victim. This typically requires the automatic transmission of authentication cookies by the browser. However, when authentication cookies are configured with Strict mode, this automatic transmission is prevented.
By essentially neutralizing this method used in CSRF attacks, SameSite=Strict significantly enhances security, providing a substantial safeguard against unauthorized actions carried out on behalf of users.
SameSite=LAX cookies
Lax implies that the cookie is excluded from cross-site requests, like those for loading images or frames. However, it is sent when a user is navigating to the origin site from an external site, such as when clicking on a link.
SameSite=Lax cookies follow the same rules as Strict cookies for several scenarios:
When typing the URL into the address bar and directly navigating to a site.
When refreshing the page using the browser.
When following a link to a page within the same site.
When embedding an iframe hosted on the same site (sharing the same domain and scheme).
When making an AJAX/fetch request within the same site using JavaScript.
Additionally, Lax cookies are sent for “top-level GET requests,” which are GET requests that modify the URL in the navigation bar. This means they are also sent when:
Following an <a> link to your site from a different domain.
A form embedded on another site sends data to your website using the GET action.
However, SameSite=Lax cookies are not sent in the following cases:
A form embedded on another site sends data to your website using POST. Lax (or Strict) cookies won’t be included in the request.
A site on another domain makes an AJAX/fetch request using JavaScript to your site; Lax (or Strict) cookies won’t be included.
If your site is embedded in an iframe on a site hosted on a different domain, your site won’t receive any Lax (or Strict) cookies.
An image on your website is directly linked in the src attribute of an <img> from another site.
Employing SameSite=Lax offers a moderate level of defense against CSRF attacks since cookies are excluded for requests categorized as “unsafe,” such as POST requests. In theory, this implies that even if there’s a CSRF vulnerability, attackers shouldn’t be able to exploit it because they can only execute “safe” actions. It’s essential to ensure that no unsafe actions are performed in GET requests to maintain this level of safety, making it not as secure as the Strict mode.
And that’s a wrap on our journey through SameSite cookies! 🍪✨ Whether you’re in Team Strict for top-notch security or rocking with Lax for that smooth user experience, it’s all about finding your cookie groove.
Remember, it’s not just about the techy stuff. SameSite cookies are like the superheroes of your web adventures, fighting off sneaky attacks and ensuring your users have a blast without compromising their safety.