Re: [whatwg/fetch] Add a way to have cookie origin and CORS origin be different (Issue #1637)

My tl;dr is that using a credentialed CORS should be fine in this case, but it seems useful to discuss why.

Today, it's obviously possible to send credentialed cross-site CORS requests. In Chrome, this is allowed by default for `SameSite=None` cookies. In other browsers it's enabled via Storage Access API or if the user disables tracking protections (either per-site, or globally); in both cases it applies to default cookies (i.e. ones without a `SameSite` attribute).

In the future, I'd like to move to a model where you can't by default attach credentials to cross-site requests, except for top-level navigations made using safe methods _or_ if a server opts into this on a per-endpoint basis. Even then, this would only apply to `SameSite=None` cookies. Of course this would have to still be bound by our privacy model -- it's not enough for the server to opt in to getting cross-site requests with cookies, there has to be some control that prevents such an opt-in from bypassing tracking restrictions.

For example, in cases that we've decided are okay from a tracking prevention perspective, e.g. if the user allows access to non-partitioned cross-site state using Storage Access API (or, more relevant to this bug,  through the FedCM flow), I think CORS is the right mechanism for servers to signal opt-in to receive authenticated cross-site requests. Speculating a bit, my guess is that we'll want to strengthen the CORS model to require preflights for credentialed cross-origin/site POSTs (to remove the arguably strange loophole that allows Fetch to send POST requests without a preflight because that had already been possible through `form#method=POST`).

So, basically, from the FedCM perspective I don't think there's a problem with allowing these requests to be made in `cors` mode, both because it's not a security regression from the status quo and because it's compatible with the long-term cookie model we're aiming for.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1637#issuecomment-1734329302
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1637/1734329302@github.com>