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.

Here are couple checks to see if this problem will affect your integrations:

  • If you have all applications and Single Sign-On (SSO) within same top-level domain then SameSite cookie flag will not affect your cookies at all. For example app.example.com, sub.app.example.com and sso.example.com subdomains are all part of the same top-level domain example.com.
  • If you have integrations to external resources or IDPs outside of your top-level domain and are using only OpenID Connect (OIDC) / OAuth 2 with them SameSite flag will not affect your integrations

Caution: unless some of the OIDC integrations are using response_mode=form_post

If you have SAML integrations to external parties outside your top-level domain in most conditions the new SameSite cookie flag default value will affect your integrations.


Technical diagram

Example of integration that will continue working in the updated version


Technical diagram

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;

Set SameSite=None in other products

These kind of configurations can be done in most reverse proxies and load balancers.

Remember to consider that not all browser versions support SameSite value None and additional checks for user agent is needed.

Still unsure if your environment is affected?

To verify if your integrations will continue working, you can change behaviour of Chrome 79 to act in similar way as Chrome 80 will by;

  1. Browsing to chrome://flags/
  2. Search for “SameSite by default cookies” and choose to “Enable
  3. Search for “Cookies without SameSite must be secure” and choose to “Enable
  4. Restart Chrome

In similar way, this can be used with Chrome 80 to disable this new behaviour of SameSite cookies;

  1. Browsing to chrome://flags/
  2. Search for “SameSite by default cookies” and choose to “Disable
  3. Search for “Cookies without SameSite must be secure” and choose to “Disable
  4. Restart Chrome

If you still have questions or concerns about this update, please contact Ubisecure technical team for more information.