Open nicktrav opened 4 years ago
The answer was that there were no plans to change the behavior here.
This has since changed, but my questions still stand on this, and the answers may be useful to others looking to use cookies when a user-content domain setup is in place.
Thoughts on this:
foo.com
and usercontent.foo.com
. Requests between these would not be cross-site and SameSite=Lax
would work as expected.
We are running into an issue in the case of user-content domain protected by an BeyondCorp style authenticating proxy, and are hoping for some guidance in best practices in this type of (increasingly common) setup.
Consider a primary domain,
foo.com
, and a companion "user content" domain,foo-usercontent.com
. The latter is used for arbitrary user content uploads and various static assets (CSS, JS, etc.), following web best practices.Both domains are protected by a BeyondCorp style authenticating proxy, that uses JWTs for authentication of every request. The same JWT can be used for authenticating on either domain. The JWT is set without the
SameSite
directive.Visiting
foo.com
issues an initial request that uses the cookie forfoo.com
in a first-party context, and returns content that must now be fetched fromfoo-usercontent.com
.Prior to Chrome v80, the Cookie with the JWT would be sent on requests to
foo-usercontent.com
, allowing them to be authenticated, and content fetched.Post Chrome v80, we get the familiar message about the Cookie being blocked from being used. As a result, static content cannot be fetched from the
foo-usercontent.com
domain, as the request is treated as unauthenticated due to the missing JWT token. The pages do not render correctly, resulting in a confusing user experience. The obvious workaround is, most unfortunately, to disable the#same-site-by-default-cookies
feature.We asked the vendor of the authenticating proxy whether they would be willing to set
SameSite=None
on the cookie and allow it to be used in cross-site requests to the user-content domain. The answer was that there were no plans to change the behavior here.The question(s):
Does the lack of
SameSite
directive, and the resultant interpretation ofSameSite=Lax
, make sense in a situation like this?Would there be any valid argument, from security perspective, in setting
SameSite=None
for this authentication cookie, allowing the cookie to be sent on requests forfoo-usercontent.com
in a third-party context, as it was before.