Same Site Changes in Chrome

Archit Agarwal
3 min readNov 22, 2019

--

As many of you might have seen this warning in Console in Chrome

A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.

So let us see what is meaning of Same Site Attribute in Cookie Header?

Same Site Meaning:

The Same Site Cookie attribute can be used to disable third-party usage for a specific cookie.When someone is requesting data from third party site, any cookie you had on the present site will also be passed in the request header. So if you don’t want to pass these cookies, then you can set SameSite=Strict and it is set by the server when setting the cookie, and requests the browser to only send the cookie in a first-party context.This effectively makes CSRF impossible, because an attacker can not use a user’s session from his site anymore.

The server can set a same-site cookie by adding the SameSite attribute to the Set-Cookie header:

Set-Cookie: key=value; Secure; SameSite=Strict

Other possible values for Same Site Attribute are None and Lax.

SameSite=Nonemeans cookies of first party will be passed in third party context.

SameSite=Lax Cookies with this setting are sent only on same-site requests or top-level navigation with non-idempotent HTTP requests, like HTTP GET.Top-level means that the URL in the address bar changes because of this navigation. This is not the case for iframes, images or XMLHttpRequests.

Chrome changes:

Google plans to add support for an IETF standard called SameSite, which requires web developers to manage cookies with the SameSite attribute component in the Set-Cookie header.

  1. SameSite by default cookies enforces the Lax value for all cookies that don’t specify the SameSite attribute:
  2. Cookies without SameSite must be secure requires that all cookies without SameSite attribute need to be Secure as well. Cookies that fail to do so will be rejected.

If you want to see how Chrome will behave in Feb 2020 when they will release this feature, just go to chrome://flags/ and search for Same Site and change default to “Enabled”.

Chrome Same Site

What you need to do?

If you want your cookies to be passed to third party usage and don’t want to get impacted because of this Chrome change, then you need to Set SameSite=None while setting the cookie response for browser Chrome.

Set-Cookie: key=value; Secure; SameSite=None

But there is a catch, versions of Chrome from Chrome 51 to Chrome 66 (inclusive on both ends),these Chrome versions will reject a cookie with SameSite=Nonefor more details check this link:

https://www.chromium.org/updates/same-site/incompatible-clients

So you have to determine the version from the user agent and then set the attribute None for Same Site only for versions above 66. Following is one sample User Agent.

User-Agent: Mozilla/5.0 (Linux; Android 9; MAR-LX1A) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.116 Mobile Safari/537.36

Here is a sample code in Scala which shows how to retrieve the Chrome version from User agent.This is a simple way to determine chrome version from user agent, otherwise you can use some library also to get the version from user agent.

def isSameSiteApplicable(userAgent: String): Boolean = {
if (userAgent == "" || userAgent.length == 0)
false

val
chromeIndex = userAgent.toLowerCase.indexOf(CHROME)
if (chromeIndex != -1) {
val index = userAgent.indexOf(".", chromeIndex)
if (index != -1) {
val version = userAgent.substring(chromeIndex + CHROME.length, index)
if (toInteger(version) >= 67) true else false
}
else false
}
else
false

}
def toInteger(s: String): Int = {
try {
s.toInt
} catch {
case e: Exception => 0
}
}

Conclusion

The same-site attribute gives the possibility to disable third-party usage for any cookie. The feature improves protections against CSRF and other attacks significantly.

--

--

Responses (1)