Everything you need to know about securing your cookies with Samesite attribute

Cookies are data containing helpful information about you and your preferences on your computer for an instance. For example, Imagine selecting certain language for a website you would visit, you tell the website “Hey, I would like to view your website and select the English language”, the website would then save that information to a little document called as a cookie on your computer through the browser. The next time when you would visit the website it would be able to read the cookie saved earlier in such a way that the website could remember your language and let you view the website in English without you having to select your language again.

Cookies are not limited to remembering just your language. In fact, a cookie can contain pretty much any kind of information. It can store the time at which you visited a website, or it can contain the items you add to your shopping cart or it can even contain the links you clicked on a certain website. What exactly is saved to a cookie depends on the development of the website you are visiting.

Cookie started containing more and more data and eventually started pushing their size limitations. Subsequently, developers came up with clever work around what if they would simply store a unique ID in a cookie on your computer and save the rest of the data in their own system. This enabled them to save unlimited amount of data. The cookie would simply serve as an identifier for your computer much like a tag by which the website recognizes you and look up your data in its own system. This was the first step towards so called third-party cookies, only same website that saved data to a cookie could access it later, but one website can contain bits of another website. These bits and pieces of other websites embedded in the website you are visiting can access cookies they save to your computer earlier.

Imagine visiting a news website- Apart from news articles, many news websites contain couple of ads. These ads are in most cases bits of other websites embedded into the news website. Now the news website you are looking at may not have saved any cookies to your computer and thus know nothing about you but where do the ads come from? It’s not unlikely that the ads on the news website are embedded from the same website as the ads on another website you visited earlier. In fact, you may visit the dozens of websites with ads which are all embedded from the same website. So what does this means that if the website the ads come from has saved a cookie to your computer earlier, it can identify you and save information about you through other websites so while you are reading the news website, shopping for new shoes the ads on those website can identify you, look up your information in their own system and dynamically show ads that you are most likely to be interested in while simultaneously saving information about what you are doing online. So, are cookies dangerous? This depends completely on the creators of a website to determine what information they do and do not store and more importantly what they use that information for cookies. Hence, it can surely be dangerous if the data stored is exploited.

Same-site cookies allow server to mitigate the risk of CSRF (Cross site request forgery) and information leakage attacks by asserting that a cookie should only be sent with request initiated from the same registered domain.

The stable version of chrome 80 is target for enabling this feature by default. This feature is available as of chrome 76 by enabling the chrome chrome://flags/#same-site-by-default-cookies flag

With chrome 80 scheduled in February 2020, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies, only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. Any cookies that request SameSite=None but is not marked Secure will be rejected by the chrome. Other browsers follow own timeline on enabling samesite cookie functionality

The introduction of the SameSite attribute allows you to mention if your cookie should be restricted to a first-party or same-site context.

DOT NET issued update to change the behavior of its SameSite attribute behavior in .NET 4.7.2 and in .NET Core 2.1 and above to reflect Google introduction of a new value. The updates for .NET framework are available since December 10th 2019. Dot NET 3.0 and 2.1 updates are released on 19th November, 2019.

If the SameSite attribute value is “Strict”, the cookie will only be sent along with same-site request if the request is from same domain in which the cookie is set .

If the value is “Lax”, the cookie will be with same-site request, and with “cross-site” top-level navigations. The request from same domain in which the cookies is set alongwith the top-level navigations that changes the browser URL,

If the value is: None”, the cookie will be sent with same-site and cross-site requests, but the cookies should be secure (secure flag in cookies) – Cookie will be sent in all the cases .

If the SameSite attribute is missing, the attribute value will be treated as “Lax”

SameSite cookies offer a robust defense against CSRF attack when deployed in strict mode, and when supported by the client but need to enable the SameSite=Lax or SameSite=None;secure based on the requirement.

Hope you shall ensure the same while using cookies in your coding the next time you are building a software module!