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

znanfelt · 2019-10-03T19:13:47Z

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

The text was updated successfully, but these errors were encountered:

paulzmuda · 2019-10-14T00:06:55Z

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

Jswk1 · 2019-10-16T08:00:58Z

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?

steveetm · 2019-10-25T07:12:38Z

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?

borgstrom · 2019-10-26T02:33:43Z

cc @grant @bochunz

grant · 2019-10-26T02:42:44Z

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.

steveetm · 2019-10-28T05:26:34Z

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.

steveetm · 2019-10-28T14:56:16Z

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

nathgilson · 2019-10-28T15:04:23Z

@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).

MathiasGilson · 2019-10-30T12:41:16Z

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

steveetm · 2019-10-30T12:49:10Z

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?

WJakub · 2019-11-01T13:12:50Z

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.

MathiasGilson · 2019-11-02T09:54:50Z

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

steveetm · 2019-11-04T14:50:30Z

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.

grant · 2019-11-04T15:19:05Z

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.

jamesgraham · 2019-11-18T12:15:39Z

This is also affecting our login for beta channel users. When can we expect Google services to be compatible with Chrome changes?

grant · 2019-11-21T18:51:58Z

The team wanted me to give this update:

SameSite Updates: https://www.chromium.org/updates/same-site
- This has the status and roadmap of the SameSite attribute.
Google is going to show a warning message to users to ask them to either move to Chrome Stable or turn off the flags.

steveetm · 2019-11-21T18:54:36Z

@grant I am on chrome stable, I have that flag turned on by default on chrome stable, never ever installed canary/chromium or any dev version, and this stuff is broken since chrome 78 stable.

chlily1 · 2019-11-21T18:56:28Z

@steveetm That doesn't sound possible based on the timeline of when we enabled things. Are you running Chrome with --enable-experimental-web-platform-features? That would include the SameSite features in 78, though we removed them from that flag in 80.

steveetm · 2019-11-22T09:27:23Z

@chlily1 it is possible, but hard to tell as when I ran into this problem manually switched flags to see if anything helps. But also got reports from end-users. What is sure for me it was working with Chrome 77 stable and got broken with Chrome 78, without change any flags between the update. Even if it is related with experimental-web-platform-features I think Chrome shouldn't tell me a warning that it will be enabled in the future when that flags is enabled(due a bug or planned change). It should throw warning it is enabled now because SameSite setting is defaults to true. But in that case this is a bug in Chrome.

Anyways, your response makes sense and I have no more questions about this, but I still feel there were some kind of chaos as it required more than a month to figure out exactly what is going on.

chlily1 · 2019-11-22T14:24:58Z

@steveetm I understand your frustration, and we've heard that feedback from others too.

We have recently updated the console messages to differentiate between warnings and actual blocking, by either saying "A future release of Chrome will..." or "It has been blocked because..." depending on the feature state. That is available in Chrome 80, and has been backported to Chrome 78, so you should see the new phrasing if your version is at least 78.0.3904.108.

paulzmuda · 2019-11-22T16:25:17Z

I think this conversation lost track of the original issue reported. Google API assets, in how they are served by Google, are not in compliant with Google Chrome present (warning) or future (blocking). Users on stable un-tampered versions of Chrome are being warned by Google about something Google is doing.

Is it agreed that we're waiting for googleapis.com / accounts.google.com to begin serving SameSite cookies?

jamesgraham · 2019-11-27T09:31:45Z

We are now 10 days away from stable.

Is there an update or should we start preparing for mayhem?

briangithex · 2019-11-27T14:15:33Z

We are now 10 days away from stable.

Is there an update or should we start preparing for mayhem?

No mayhem. Chrome 79 stable will still have this feature disabled by default. Chrome 80 will have it enabled by default. Chrome 80 will be released around Feb 4.

References:
https://www.chromium.org/updates/same-site
https://chromestatus.com/features/schedule

Specifically, pay attention to the launch timeline (i.e., the three date bullet points) on https://www.chromium.org/updates/same-site . Notice that stable users are unaffected until Feb 4, 2020.

twistedfork88 · 2019-12-07T19:07:41Z

Ah, the main point to note is this got enabled even in 78 stable mostly due to:

* Unless you have explicitly activated them via chrome://flags, or unless you are running Chrome with the --enable-experimental-web-platform-features flag.

"Experimental Web Platform features" flag being enabled. In that case, I don't think this change is impacting our customers (unless they tamper with the flags) that much as us devs.

grant · 2019-12-11T21:31:21Z

Hi all,
Are there any lasting concerns that I should communicate to the team? The team has mentioned that this issue should be resolved as of now.

paulzmuda · 2019-12-11T22:17:05Z

@grant nope just waiting for Chrome 80 to start blocking Google API.

MathiasGilson · 2019-12-12T07:04:12Z

@grant still not working for me on Chrome MacOS 79.0.3945.79 (Official Build) (64-bit)
but canary is working on Chrome MacOS 81.0.3992.4 (Official Build) canary (64-bit)

foucdeg · 2020-09-03T12:04:16Z

@sergentj unnecessary warnings aren't harmless to developer experience.

cspowell1225 · 2020-09-09T16:43:53Z

Sounds like we have the same issue, the google translate API is causing issues in dev tools in regards to cookie security, but I can't seem to figure out a way to configure the cookie to satisfy Chrome's standards.

I'll be watching this issue and hoping that the translate API gets updated so we aren't ignoring the errors that dev tools reports.

netsider · 2020-09-09T16:50:37Z

I was going to upvote the reply that said Chrome is actively rejecting these cookies, because it definitely is (depending on how chrome://flags is configured, anyway -- I had to disable samesite cookies for it to ignore it).

juanpablocs · 2020-09-11T14:44:20Z

any of you have any news of this problem? how much longer do we have to wait?

khanks · 2020-09-13T20:34:43Z

Disabling samesite cookies is not really going to help those of us who have client users scattered all over the place, is it? I don't control the browser or settings for users. Besides, my site doesn't, on it's own, even use 'cookies' -- I don't use or allow a Google or Facebook login (or any other type of 3rd-party login) to my site. I'm unsure why anyone would use that anyway, but that's another topic for another thread. So this thing is completely ridiculous as far as my site is concerned. Just venting ...

CarlosGongoraInterlink · 2020-09-23T17:51:41Z

All the comments are quite interesting. I have a GAS web app and it doesn't run in Chrome! that's hilarious! Also, I wonder why the thread is closed when the issue has not been resolved... my app works fine in Firefox but for how long? this is quite frustrating...

arvindpdmn · 2020-09-24T06:52:14Z

This error now appears in Firefox 80.0.1.

omri-trem · 2020-09-29T20:14:37Z

Any update on this? I'm unable to use authentication because of this error.

zauzaj · 2020-09-30T15:17:12Z

I have an issue with the setting cookie too.
So we have rails api + react app on FE. I'm setting cookie on the backend with httpOnly: true and secure so cookie has to be written on backend app cookie storage but it is not. Even when I disable all 3 flags that are mentioned above, it doesn't work. Any thoughts?

NAllred91 · 2020-10-04T18:52:24Z

Seems to still be broken in Chrome 85 on Android. Disabling "SameSite by default Cookies" fixes the issue.

Is there any expectation that this will work, or is there an alternative to gapi that is more actively maintained?

NAllred91 · 2020-10-04T19:13:40Z

Somehow after uninstalling and reinstalling Chrome I now have version 80, and everything works as expected.. Don't know how to update again to 85 to confirm its still broken for me.

Nagendracv · 2020-10-16T09:34:50Z

Sad that is issue is marked closed...!! Why is it closed. So many issues with samesite=none in spite of marking secure.

ChannelJuanNews · 2020-10-24T03:54:59Z

I am having the same problem. I do not understand why it is rejecting these cookies when I am putting these options with express.js

I have scoured the internet and I do not understand why this is happening. Can someone explain why the HttpOnly cookie is being rejected?

server.js

res.cookie('token', token,   { 
    domain: 'https://127.0.0.1:3000',
    path : "/endpoint",
    maxAge : 24 * 60 * 60 * 7, // 7 days
    httpOnly: true,
    secure: true,
    sameSite : "none"
});

And this is the Response Header that is being set

Chrome Network Tab Headers

Set-Cookie: token="somestring"; Max-Age=604; Domain=https://127.0.0.1:3000; Path=/endpoint; Expires=Sat, 24 Oct 2020 03:56:54 GMT; HttpOnly; Secure; SameSite=None

And this is the error code that I am getting

Chrome Network Tab Exclamation Point Error

this set cookie was blocked because its domain attribute was invalid with regards to the current host url

ChannelJuanNews · 2020-10-26T18:23:26Z

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.

sedhha · 2020-11-12T13:49:16Z

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

sergentj · 2020-11-12T17:22:04Z

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.

Nagendracv · 2020-11-13T18:23:58Z

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> .

akdu12 · 2020-11-26T20:02:59Z

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

sedhha · 2020-11-28T13:14:15Z

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

bangnguyendev · 2021-02-19T08:42:08Z

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/

MattG561 · 2021-06-10T19:12:49Z

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

clemsontiger · 2021-06-16T17:46:12Z

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

Julian-Silvestri · 2021-07-09T03:30:54Z

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

khanks · 2021-07-09T03:36:59Z

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.

Julian-Silvestri · 2021-07-09T03:46:16Z

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

Mahdiyeh · 2021-08-11T15:20:55Z

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?

SyedHusaini · 2021-08-20T04:54:08Z

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!

yangfan-coder · 2022-01-25T06:33:36Z

名称域和路径
詹金斯时间戳偏移量本地主机/
_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

znanfelt changed the title ~~Cross-site cookie not 'SameSite' warning~~ New cross-site cookie not 'SameSite' warning in Chrome Oct 3, 2019

somcoder mentioned this issue Oct 25, 2019

Possible issue with attribute SameSite abacritt/angularx-social-login#215

Closed

steveetm mentioned this issue Nov 15, 2019

window.gapi.auth2.getAuthInstance().signIn doesn't send callback in Chrome #571

Open

arvindpdmn mentioned this issue Nov 4, 2020

Cookie issues DevopediaOrg/webapp#488

Closed

nadorator mentioned this issue Feb 23, 2024

Third party cookies from google tag manager 'SameSite None' warning in Chrome #1200

Open

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

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

Comments

znanfelt commented Oct 3, 2019 • edited Loading

paulzmuda commented Oct 14, 2019

Jswk1 commented Oct 16, 2019 • edited Loading

steveetm commented Oct 25, 2019

borgstrom commented Oct 26, 2019

grant commented Oct 26, 2019 • edited Loading

steveetm commented Oct 28, 2019

steveetm commented Oct 28, 2019

nathgilson commented Oct 28, 2019

MathiasGilson commented Oct 30, 2019

steveetm commented Oct 30, 2019

WJakub commented Nov 1, 2019

MathiasGilson commented Nov 2, 2019

steveetm commented Nov 4, 2019

grant commented Nov 4, 2019 • edited Loading

jamesgraham commented Nov 18, 2019

grant commented Nov 21, 2019

steveetm commented Nov 21, 2019

chlily1 commented Nov 21, 2019

steveetm commented Nov 22, 2019

chlily1 commented Nov 22, 2019

paulzmuda commented Nov 22, 2019 • edited Loading

jamesgraham commented Nov 27, 2019

briangithex commented Nov 27, 2019 • edited Loading

twistedfork88 commented Dec 7, 2019 • edited Loading

grant commented Dec 11, 2019

paulzmuda commented Dec 11, 2019

MathiasGilson commented Dec 12, 2019

foucdeg commented Sep 3, 2020

cspowell1225 commented Sep 9, 2020

netsider commented Sep 9, 2020

juanpablocs commented Sep 11, 2020

khanks commented Sep 13, 2020

CarlosGongoraInterlink commented Sep 23, 2020

arvindpdmn commented Sep 24, 2020

omri-trem commented Sep 29, 2020

zauzaj commented Sep 30, 2020

NAllred91 commented Oct 4, 2020

NAllred91 commented Oct 4, 2020

Nagendracv commented Oct 16, 2020

ChannelJuanNews commented Oct 24, 2020

ChannelJuanNews commented Oct 26, 2020

sedhha commented Nov 12, 2020

sergentj commented Nov 12, 2020

Nagendracv commented Nov 13, 2020 via email

akdu12 commented Nov 26, 2020

sedhha commented Nov 28, 2020 • edited Loading

bangnguyendev commented Feb 19, 2021

MattG561 commented Jun 10, 2021

clemsontiger commented Jun 16, 2021

Julian-Silvestri commented Jul 9, 2021

khanks commented Jul 9, 2021

Julian-Silvestri commented Jul 9, 2021

Mahdiyeh commented Aug 11, 2021

SyedHusaini commented Aug 20, 2021

yangfan-coder commented Jan 25, 2022

znanfelt commented Oct 3, 2019 •

edited

Loading

Jswk1 commented Oct 16, 2019 •

edited

Loading

grant commented Oct 26, 2019 •

edited

Loading

grant commented Nov 4, 2019 •

edited

Loading

paulzmuda commented Nov 22, 2019 •

edited

Loading

briangithex commented Nov 27, 2019 •

edited

Loading

twistedfork88 commented Dec 7, 2019 •

edited

Loading

sedhha commented Nov 28, 2020 •

edited

Loading