SameSite cookie changes explained. SameSite=lax vs SameSite=none.

What is a SameSite cookie?

Cookies are used by websites for example to persist states, add information or track usage. There are different attributes that cookies can have, one of which is SameSite that was introduced to control which cookie can be sent together with cross-domain requests. Up to now, browsers allow any cookie that doesn’t have this attribute set to be forwarded with the cross-domain requests as default.

On the week of 17th of February 2020 Google releases Google Chrome version 80 which is changing the default behaviour of cookies that are used in cross-domain use cases. Updates related to release can be found from here https://www.chromium.org/updates/same-site

SameSite=Lax. What does this mean?

The introduced changes will treat any cookie that doesn’t have a value set for SameSite to default SameSite=Lax, instead of the previous default SameSite=None.

These cross site cookies will also require that your services are running on HTTPS in order to work. More information can be found from here https://blog.chromium.org/2019/10/developers-get-ready-for-new.html.

In order to mitigate these issues, we have tested and verified a workaround to make sure that services continue to work as before until other browser vendors follow same behaviour.

If there are applications or services that are communicating between different top-level domains you need to take the following actions to ensure that those continue to operate as before. You can expect to see this issue with HTTP POST requests between domains. For example in SAML Assertion methods when the SAML response from IDP is sent back using HTTP POST.

NOTE: If you are using load balancer cookies for sticky sessions these cookies will be affected as well.

An example on how to update your proxy to set SameSite=None for Chrome version 80 is available below. This will add required attribute to all cookies that are accessing your service(s) and require to communicate between different top-level domains. When using SameSite=None it is required that the “Secure” flag is also set for the cookie.

We are continuously monitoring the development from other browsers. As appropriate we will make updates to our software to manage the SameSite attribute. As of now there are incompatibility issues with some browser vendors; https://www.chromium.org/updates/same-site/incompatible-clients. We recommend that you use this list to build a robust solution for adding the cookie flag to all except the listed incompatible clients.

Does the SameSite Cookie changes affect my environment?

When the new default value Lax for SameSite cookie flag is implemented in browsers, it will prevent sending cookies with the unsafe HTTP methods (e.g. POST) when navigating between sites. We highly recommend testing all your integrations.

Example of integration that will continue working in the updated version

Example of integration that will stop working in the updated version

Additional special cases that will be affected by the new default value if they are not within same top-level domain:

• SAML single logout endpoint can be HTTP POST
• Single Sign-On (SSO) session status check and refresh remote Javascript calls

Set SameSite=None flag for Nginx reverse proxy

This will affect Chrome major versions 80 to 89.

For adding the flag in Nginx the best way currently is to use proxy_cookie_path directive in Nginx configuration. There is a module for setting the flag directly but as of writing the module doesn’t yet support None as value.

First add a “map” to your “http” section for mapping certain user agents to the flag. Then in your “location” block you need to use “proxy_cookie_path” to append the map result to “/” and “/uas” paths. This change will preserve other flags already set to the cookies like Secure or HttpOnly.

You can easily add new regex mappings to the map when new browsers start using the SameSite=Lax as default. Ensure that they map to the same string as in Chrome 8*. If you want to test your own Chrome version with this Nginx configuration, replace the “8[\d]” in the regex with your Chrome major version (eg “79”) and restart Nginx

http {
 
  map $http_user_agent $samesite_none {
    default                         "";
    "~Chrom[^ \/]+\/8[\d][\.\d]*"      "; SameSite=None";
  }
   
  # Your other http directives...
  server {
   
    # Your other server directives...
 
    location / {
   
      # Your other location directives...
 
      proxy_cookie_path /uas /uas$samesite_none;
      proxy_cookie_path / /$samesite_none;
    }
  }
}