The front-end is 192.168.123.90, and the back-end is 192.168.123.2. This morning I found that the user login reported a login failure (essentially because cookies could not be set). At first, I thought there was something wrong with the back end, but recently I did not change the logics related to user login. Later, it is ok to switch to Firefox and Edge, and some people can log in normally with Google.

The debug message for the offending Google browser reports the following error:This set-cookie didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax" and broke the same rules specified in the SameSiteLax value Combined with the above analysis, the preliminary judgment is that the new Version of Google browser for Cookie cross-domain restrictions.

As of Chrome 51, a SameSite attribute has been added to the browser Cookie to prevent CSRF attacks and user tracking. This setting is currently off by default. After Chrome 80, this feature is enabled by default.


1. Quick solutions

For browsers after Google 80

1.1 disable SameSite

Google Chrome accesschrome://flags/#same-site-by-default-cookiesAddress, set this option for cookies to disabled, and restart the browser.

1.2 Modifying source Code

In set-cookie, change the SameSite property value to None and set the Secure property to true. However, the domain name of the back-end service must be accessed using HTTPS.

The best solution is to use token instead of Cookie to authenticate user login


2, Samesite

cookiesSameSiteProperty is used to limit third-party cookies, thereby reducing security risks.

It can set three values:

  • Strict
  • Lax
  • None

2.1 Strict

Strict is the strictest and completely forbids third-party cookies. Cookies are never sent across sites under any circumstances. In other words, cookies are carried only if the URL of the current web page matches the target of the request.

Set-Cookie: CookieName=CookieValue; SameSite=Strict;
Copy the code

This rule is too strict and can lead to a very bad user experience. For example, if there is a GitHub link on the current webpage, users will not have GitHub cookies when they click the jump, and the jump will always be unlogged.

2.2 Lax

The Lax rule is slightly relaxed, and third-party cookies are also not sent in most cases, except for Get requests that navigate to the target url.

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Copy the code

A GET request to navigate to a target url consists of only three cases: links, preloaded requests, and GET forms. See the table below.

Request type The sample normal Lax
link <a href="..." ></a> Send a Cookie Send a Cookie
preload <link rel="prerender" href="..." /> Send a Cookie Send a Cookie
GET the form <form method="GET" action="..." > Send a Cookie Send a Cookie
POST form <form method="POST" action="..." > Send a Cookie Don’t send
iframe <iframe src="..." ></iframe> Send a Cookie Don’t send
AJAX $.get("..." ) Send a Cookie Don’t send
Image <img src="..." > Send a Cookie Don’t send

Setting Strict or Lax basically eliminates CSRF attacks. Assuming, of course, that the user’s browser supports the SameSite property.

2.3 None

Chrome plans to make Lax the default. At this point, the site can choose to explicitly turn off the SameSite property and set it to None. However, the Secure attribute must be set at the same time (cookies can only be sent through HTTPS). Otherwise, cookies are invalid.

The following Settings are invalid.

Set-Cookie: widget_session=abc123; SameSite=None
Copy the code

The following Settings are valid.

Set-Cookie: widget_session=abc123; SameSite=None; Secure
Copy the code

Refer to the link: www.ruanyifeng.com/blog/2019/0…