New cross-site cookie not 'SameSite' warning in Chrome

Hello,

I am wondering if anyone else has run into the following warning related to cross-site cookies with the latest version of Chrome. Per the documentation, Chrome version 80 will only deliver cookies set correctly. Is this something that I can fix in my application or something that we need for Google to fix?

A cookie associated with a cross-site resource at https://accounts.google.com/ 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 https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032

To reproduce above warning, go to google's example sign-in website in chrome 77+ and view the logs the console: https://developers.google.com/identity/sign-in/web/sign-in

Same problem even by adding res.header("Set-Cookie", "HttpOnly;Secure;SameSite=None"); to my server it seems something similar needs to be added on Google's where they are serving https://apis.google.com/js/api.js

Using:
Chrome Version 77.0.3865.90 on MacOS Mojave

Same problem and also signIn method on auth instance from gapi.auth2.getAuthInstance() has stopped working once I enabled this flag in current version of Chrome (Win10, 77.0.3865.120). Can anything be done about this or is this something that should be fixed on Google side?

Guys, do anyone has any update on this? With chrome 78 signIn suddenly stopped working, I can't really ask users to go into chrome://flags and disable something.
Also, I read the chromestatus links again, and I still think this should be enabled by default only in chrome 80, what happened?

@grant

cc @grant @bochunz

Will look into this Monday and report a bug to the team when I can reproduce. 🙂
EDIT: Added internal bug b/143761058 and reported to the team. I will update this GitHub issue if there are updates.

If you interested in a production site which is affected for sure, go to wish.com and try to login with google. Again, it is working fine if you disable those flags.

Sorry for being hasty there, but I can't believe it is affecting only us. Any update?

@grant

@grant said he will report this bug to the team. It might not last long before it's getting fixed...
I found many apps having the same problem, but it concerns only a minority of users using the last version of chrome (cf canary deployment).

@grant

@grant when disabling the following flags on chrome the login works

For me it was enough to disable 'SameSite by default cookies'.

Do you guys know if this is a bug in this lib, or Chrome 78 accidentally enabled this flag 2 releases earlier?

After successfully integrating Google Calendar API using gapi library yesterday, I saw my Chrome was out of date.

After updating to v78, the integration stopped working - Sign in popup showed, I could 'sign in' but after the popup closed, nothing happened in the app. No errors though!

3 hours into figuring out what I changed in my codebase, I came across this thread - turns out the 3 flags set to disabled make it work fine again.

Of course, there are warnings about it in the console, but they mention it's due to be changed in FUTURE RELEASE.

I believe this was shipped accidently in v78, however the warnings are not errors because they are yet to be updated as it was meant to ship in later version.

@grant

@grant did you have time to look at it?
Your help would be really appreciated on this one 🤗

As I am still not sure whose fault is this and what is the exact issue I really don't want to rant or anything, but we decided to remove google login at this point. Don't get me wrong, it was planned to do something about the warning, but as this was only a warning to get ready this was totally unexpected. 19 days passed since the original report, you could easily say that forget this method, or something, but this lack of information is totally disappointing.

I assure you this is being looked at. There were updates today internally.

I updated that comment 3 days ago before the weekend. I've increased the priority of the internal issue.

I was finally able to get this to work by omitting the Domain attribute using Express.js and Node.

It is also noteworthy that I am serving the website on https://127.0.0.1:3000 and I have enabled self-signed certificates so chrome won't throw an SSL error. (e.g. I am developing over https locally)

res.cookie('token', token,   { 
   path : "/api/v1/auth/fb/callback",
   maxAge : 24 * 60 * 60 * 7, // 7 days
   httpOnly: true,
   secure: true,
   sameSite : "none"
});

This is the response Header for the Set-Cookie Attribute

Set-Cookie: token=somestring; Max-Age=604; Path=/endpoint/of/request; Expires=Mon, 26 Oct 2020 18:29:32 GMT; HttpOnly; Secure; SameSite=None

Shout out to Lily Chen @ chromium for helping me solve this issue. I really appreciate it.

Wow this is 12 November 2020 and I am facing the same issue with React JS react-google-login library. I am using Microsoft Edge and the warning seems to persist. Here is my code:

<GoogleLogin 
                                        clientId ={jsonData.clientId}
                                        buttonText = {"Login"}
                                        onSuccess = {(response) => this.responseGoogle(response,this.props)}
                                        onFailure = {this.responseGoogle}
                                        cookiePolicy = {"single_host_origin"}
                                        isSignedIn = {true}
                                />

Does anyone got some solution for the same? Is it fine to ignore this warning? Will it affect my production website in any way?

Here is the warning message I get:

Because a cookie's SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.

Resolve this issue by updating the attributes of the cookie:
Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests

Hi,

My understanding is that it's a known issue that some Google Accounts cookies (e.g. SID) generate this warning, but it's safely ignorable. They are emitting the old-style cookies still for backwards compatibility reasons which are too complex to go into here. They also issue newer cookies which have the proper SameSite attributes.

If other cookies that aren't from Google Accounts in your application generate this warning it might be more serious.

For us, the issue got resolved by removing the samesite requirement for cookies. We never actually needed to set it as we did not have multiple domains. However when this attribute was introduced, things worked only when we set it. Now everything seems to work fine in browser.

…

On Thu, Nov 12, 2020 at 10:52 PM Jonathan Sergent ***@***.***> wrote: Hi, My understanding is that it's a known issue that some Google Accounts cookies (e.g. SID) generate this warning, but it's safely ignorable. They are emitting the old-style cookies still for backwards compatibility reasons which are too complex to go into here. They also issue newer cookies which have the proper SameSite attributes. If other cookies that aren't from Google Accounts in your application generate this warning it might be more serious. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AESI6BAC3O6YMQCWCE7JVHLSPQKVBANCNFSM4I5HDGLA> .

@sedhha

@sedhha did you solve it? I have the same issue and apparently it blocks sign in from working

@akdu12

@akdu12 unfortunately no. For now, I am just ignoring it... as everyone said but not sure what will be it's impact.

Name	Domain & Path
jenkins-timestamper-offset	localhost/
_ga	localhost/
_gid	localhost/
OTZ	www.google.com/
SID	.google.com/
HSID	.google.com/
SSID	.google.com/
APISID	.google.com/
SAPISID	.google.com/
S	.google.com/
UULE	www.google.com/
SIDCC	.google.com/
SID	.google.com.vn/
HSID	.google.com.vn/
SSID	.google.com.vn/
APISID	.google.com.vn/
SAPISID	.google.com.vn/
cppo	.facebook.com/

Any update on this? It's been almost 2 years..

Same here, we still use google translate and it's still showing up for the google translate related cookies....

bump ....
Why this closed....
bump !

bump ....
Why this closed....
bump !

Because if you haven't figured it out by now, you're not going to figure it out at all.

bump ....
Why this closed....
bump !

Because if you haven't figured it out by now, you're not going to figure it out at all.

lolz k thanks

Name Domain & Path
jenkins-timestamper-offset localhost/
_ga localhost/
_gid localhost/
OTZ www.google.com/
SID .google.com/
HSID .google.com/
SSID .google.com/
APISID .google.com/
SAPISID .google.com/
S .google.com/
UULE www.google.com/
SIDCC .google.com/
SID .google.com.vn/
HSID .google.com.vn/
SSID .google.com.vn/
APISID .google.com.vn/
SAPISID .google.com.vn/
cppo .facebook.com/

May I ask what does it mean? Is it a question? an error? Or a response?

I ran into this issue a while back when trying to figure out why my cookies wouldn't set in Chrome despite working no Firefox. Here is what I figured out:

If you are running your client-side and server on an http connection, you do not need to set the SameSite or Secure attribute.
The SameSite attribute will default to Lax and cookies will work.

However, if you are running your client-side on an https connection, you need to make sure that your server is also running on an https connection.
In this case, set Secure to true and SameSite to None.
This should work!

名称域和路径
詹金斯时间戳偏移量本地主机/
_ga 本地主机/
_gid 本地主机/
OTZ www.google.com/
SID .google.com/
HSID .google.com/
SSID .google.com/
APISID .google.com/
SAPISID .google.com/
小号 .google.com/
优乐 www.google.com/
SIDCC .google.com/
SID .google.com.vn/
HSID .google.com.vn/
SSID .google.com.vn/
APISID .google.com.vn/
SAPISID .google.com.vn/
cppo .facebook.com/
Excuse me, do you know how to prevent these cookies? I'm working on privacy related projects. I don't know how to prevent cookie injection? Maybe you have some information or something

Navigation Menu

Repository navigation

New cross-site cookie not 'SameSite' warning in Chrome #561

60 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

New cross-site cookie not 'SameSite' warning in Chrome #561

Description

Activity

paulzmuda commented on Oct 14, 2019

Jswk1 commented on Oct 16, 2019

steveetm commented on Oct 25, 2019

borgstrom commented on Oct 26, 2019

grant commented on Oct 26, 2019

steveetm commented on Oct 28, 2019

steveetm commented on Oct 28, 2019

nthglsn commented on Oct 28, 2019

MathiasGilson commented on Oct 30, 2019

steveetm commented on Oct 30, 2019

WJakub commented on Nov 1, 2019

MathiasGilson commented on Nov 2, 2019

steveetm commented on Nov 4, 2019

grant commented on Nov 4, 2019

60 remaining items

ChannelJuanNews commented on Oct 26, 2020

sedhha commented on Nov 12, 2020

sergentj commented on Nov 12, 2020

Nagendracv commented on Nov 13, 2020

akdu12 commented on Nov 26, 2020

sedhha commented on Nov 28, 2020

bangnguyendev commented on Feb 19, 2021

MattG561 commented on Jun 10, 2021

clemsontiger commented on Jun 16, 2021

Julian-Silvestri commented on Jul 9, 2021

khanks commented on Jul 9, 2021

Julian-Silvestri commented on Jul 9, 2021

Mahdiyeh commented on Aug 11, 2021

SyedHusaini commented on Aug 20, 2021

yangfan-coder commented on Jan 25, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions