When we tested the app made by auth0, we found that the samesite attribute was not set in the set- cookie. When getting a token, the response header has four set-cookies. The last two set-cookies are not set. We want to update them manually, but we don’t find the setting location in the management screen. Can you tell us where to set them?
Hi @lliuxu,
Welcome to the Auth0 Community!
This isn’t something you would typically have to set up manually. Are you running into a specific issue? Also, can you give an example (screenshot) of the cookies you are referring to?
Thank you for your support!
The samesite attribute is not set in cookie 「_legacy_auth0.ip*********************.is.authenticated」「_legacy_auth0.is.authenticated」, which seems to contain sensitive information such as session IDs.
The response of my application looks like the yellow part in the screenshot below.
Those are fallback cookies for browsers that don’t support same site attributes. It is clearly stated in the docs here:
Thankyou for your support.
I also read this article, but I don’t know where and how to set it? Can you tell me?
Thank you for your support.
Our customer requires that lax be set, but none is not required. Can this be updated manually?
No. These cookies are set this way deliberately.
Thank you for your support.
Our customers now complain that there are security vulnerabilities (such as CSRF) because they do not set samesite. They want to set samesite = lax. However, this cannot be updated manually. How do you consider this? Or what solutions do you have?
「_legacy_auth0.ip*********************.is.authenticated」「_legacy_auth0.is.authenticated」
Hi @lliuxu,
Can you confirm is this in regards to the compat cookies or the .is.authenticated cookies? Or both? The compat cookies are set without samesite attributes intentionally, if I am not mistaken.
I have confirmed that it should be the is. authenticated.How do you consider this? Or what solutions do you have?
Thanks for providing the extra info. I am reaching out to the team and I’ll report back.
Do you have an example of how this can cause CSRF?
Sorry, I didn’t.This is the problem pointed out by our customers.
Okay. It doesn’t look like this cookie will have that effect. Are they mistaking it for the session cookie?
Thankyou for you support.
Note:
LaxreplacedNoneas the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
from: Set-Cookie - HTTP | MDN
Our customers’ instructions are as follows:
Proper settings may prevent cross-site request forgery from running. The SameSite attribute is not set in the cookies “_legacy_auth0.xxxxx.is.authenticated” and “_legacy_auth0.is.authenticated” that seem to store sensitive information such as session ID.
I now want to be able to set samesite = lax.
Can you provide a solution?
It’s not possible to manually set it. The team had this to say:
We explicitly set it to
nonewhen saving cookies, at least for HTTPS. If no HTTPS, we use the browser default by not specifying a value at all.https://github.com/auth0/auth0-spa-js/blob/0c6166c0f1dd7c8405b7231d0074c1eb0d8a164f/src/storage.ts#L36If they’re testing on
localhost, it could be (I’m assuming Chrome) defaulting tolaxif the SameSite attribute is not specified. See this Chrome feature which started rolling out from July 2020. So it could be Chrome just reporting that default.When SameSite was implemented in this SDK, we decided at the time to specify
nonewhen running on HTTPS, and not specify anything at all (inherit browser defaults) when not running on HTTPS.
Hope that helps.
Thank you for your support.
Check if there is any other way to deal with it other than “Cookie SameSite attribute not set”.
Are you running it on localhost?
Thank you for your support.
https://xxxxxxxx.com/ Implemented in the environment.
Note:
LaxreplacedNoneas the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
from :Set-Cookie - HTTP | MDN
↓↓Here are the details given to us by our customers
Proper settings may prevent cross-site request forgery from running.
The SameSite attribute is not set in the cookies “_legacy_auth0.ip**********.is.authenticated” and “_legacy_auth0.is.authenticated” that seem to store sensitive information such as session ID.
The following values can be set for the SameSite attribute.
-Strict
No longer sends cookies when crossing different domains. For example, if you have a cookie for site A and you are accessing site B and you follow the link for site A on site B, the cookie will not be sent.
-Lax
Cookies will not be sent except when transitioning across different domains and GET. For example, POST forms and requests to other domains via img, iframe, XHR, etc. do not send cookies.
-None
A cookie is also sent when transitioning from a site in another domain.
Of the above, specifying Strict or Lax is a mitigation measure against cross-site request forgery attacks. It is just a mitigation measure and cannot be completely prevented. Also, depending on the browser, the SameSite attribute may not be available.
Our customers are worried about CSRF attacks if they don’t set Samesite = lax.
Are you sure that the current setting (without setting samesite = LAX) will not cause security problems (e.g. CSRF)? I will report to my customers.