Fetch: SameSite cookies aren't sent on credentialed CORS requests

[1lastBr3ath]

Since CORS is to enable SOP bypass, cookies are expected to be sent along as long as the request is permitted. And, CORS does have the policy to only allow credential requests.

Currently, even if a site explicitly allows credentialed CORS requests from 3rd domains, SameSite cookies aren't sent. This might break some sites if only authenticated requests are served.

Since CORS is a opt-in mechanism, it would be nice to act as the policy says. If it allows credentialed requests, SameSite cookies should be sent as well.

[annevk]

CORS is opt-in on the response though. This would allow timing attacks on the resource so doing this would require some new kind of opt-in, as well as a mandatory preflight.

[annevk]

cc @whatwg/security

[1lastBr3ath]

That would mean credentials requests will always get preflighted, right?

[annevk]

Yes, at least those where the requester wants to enable samesite cookies.

[luh2]

I just ran into the same issue.

@annevk Not sure I understood your comments - shall this be fixed or is this supposed to be kept this way?

[annevk]

I suspect this will be kept this way, but this issue remains open for now as it's not as clear as it could be in the standard.

[Shahor]

Hello,

I just got bit by this and spent a lot of time understanding what the issue was :|

I use cookies to make authenticated cross domain requests from domain.com to subdomain.domain.com.

Because of SameSite: Lax I can't make my requests (that was very painful to debug >_<) even though I passed all the preflight queries properly.

I understand now the purpose of the SameSite: Lax value, but in my context it is an issue because I either:

• Remove this option, and open myself to CSRF (although I'm working on an API this might be less of an issue but still)
• Keep this option and can't authenticate at all :|

Is there anything you would recommend on this situation?

[arturjanc]

One possible workaround is to use two authentication cookies, one regular and one marked as SameSite. On most endpoints your authentication code would require both cookies to be present, but for requests to endpoints which expect CORS requests you could only authenticate the user with the regular, non-SameSite cookie.

[Shahor]

But then you are open the same way to CSRF attacks, aren't you 🤔 ?

[arturjanc]

Yes, the part of your site which expects to respond to CORS requests could still be vulnerable to CSRF. But requests to this part of your site will be made in cors mode so you can check the Origin header and make sure that the request is sent same-site, getting protection equivalent (or very close) to what SameSite cookies offer.

[Shahor]

Yes, I was actually going to perform those verifications in a middleware besides my cors handling, thanks to a friend's suggestion.

In that mode you can still use the one cookie version, to avoid complicating that process :)

[tmccombs]

What if there was an additional SameSite mode between none and lax, which meant that cross-site requests are allowed to send the cookie, provided that the domain of the origin is "allowed". Where "allowed" could either mean matching a whitelist specified in another cookie directive (or part of the SameSite directive), or by making a mandatory preflight to check cors headers.

[annevk]

@mikewest ^

[mikewest]

What if there was an additional SameSite mode between none and lax, which meant that cross-site requests are allowed to send the cookie, provided that the domain of the origin is "allowed".

If you squint a bit, this is more or less what I proposed in https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty. Given our experience thus far with changing SameSite's default behavior in Chromium, this kind of thing is more difficult then we expected it to be. The behavior of some browsers (thos on iOS 12 in particular) make deployments complicated. We did a bad job keeping that joint oiled, and I think it's going to be more trouble than it's worth to bend any further than we're already pushing it.

[annevk]

Closing this as by design. This will be further clarified in the specification once #693 is fixed.

[tmccombs]

If you squint a bit, this is more or less what I proposed in https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty.

Kind of. Except that it depends on "First party sets" which can only be defined once for the entire site. Whereas my proposal allows more granular control over which domains are allowed to make requests containing each cookie.