Sending SameSite=Lax cookies for FedCM requests

[Christian Biesinger]

Hello net-dev,

(some context: https://github.com/w3c-fedid/FedCM/issues/587)

I had a previous discussion in chrome-security-owp about sending SameSite=Lax cookies for FedCM requests (including POST requests), and that group was satisfied with making that change.

Now I am looking at how to implement this and so I am asking this group for advice.

At a high-level, what I want is "if request->destination() == WebIdentity(), include SameSite=Lax cookies (in addition to SameSite=None)" (but do not send SameSite=Strict)

I believe this is the code to change:

https://source.chromium.org/chromium/chromium/src/+/main:net/cookies/cookie_base.cc;l=363;drc=8a5af199283ad2c25a4a0743d90d43ddc41399b4

But how should I get this information to this place?

I believe this is where the CookieOptions get created:

https://source.chromium.org/chromium/chromium/src/+/main:net/url_request/url_request_http_job.cc;l=834;drc=48d6f7175422b2c969c14258f9f8d5b196c28d18;bpv=1;bpt=1

Some thoughts that occur to me:

- Add a boolean `force_allow_same_site_lax_cookies`, set it to true in that caller if destination==WebIdentity

- Override the SameSiteCookieContext::ContextType to SAME_SITE_LAX if destination==Webidentity

- Add the request destination to CookieOptions, check that in IncludeForRequestURL

- Something else?

Any advice?

Thanks!
Christian

[Matt Menke]

So the proposal is that any renderer process sending a fetch directly to /.well-known/webidentity would get to send samesite=lax cookies to the URL? I'm very much not a cookies person, but I'd be reluctant to add more capabilities for renderers to interact with 3P cookies. I thought the IDP code was mostly in the browser process?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPTJ0XGGPL0TBQUo_Asrqak-cTax84Mb4-xeNKk2r2pZH%2BCckg%40mail.gmail.com.

[Christian Biesinger]

No, that is not the proposal? I don't know where you got the renderer aspect from.

The well-known request is not credentialed; only the accounts endpoint and the ID assertion endpoint are.

I don't know if renderers can set the request destination arbitrarily; if they can, we should certainly disallow them setting it to WebIdentity. I want this, as you suggest, from the browser process.

To be clear, by "destination" I meant https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/mojom/fetch_api.mojom;l=26?q=RequestDestination%20f:mojom%20-f:gen&ss=chromium

Christian

[Matt Menke]

Renderers can request any URLs they want, that includes .well-know URLs. I had assumed you wanted to have net/ check the path because the caller didn't have privileges to configure requests itself.

If this isn't something we want renderers to do, then gating it on path doesn't make any sense - if we can't configure the URLLLoaderFactory/ResourceRequest to send lax cookies using current APIs (I'm not entirely clear on why we can't do that), then we should add a ResourceRequest::TrustedParam to do this, so that renderers can't use it.

On Tue, Sep 16, 2025 at 12:58 PM Matt Menke <mme...@chromium.org> wrote:

Renderers can request any URLs they want, that includes .well-know URLs. I had assumed you wanted to have net/ check the path because the caller didn't have privileges to configure requests itself.

If this isn't something we want renderers to do, then gating it on path doesn't make any sense - if we can't configure the URLLLoaderFactory/ResourceRequest to send lax cookies using current APIs (I'm not entirely clear on why we can't do that), then we should add a ResourceRequest::TrustedParam to do this, so that renderers can't use it.

[Christian Biesinger]

I don't understand why you are talking about URLs. By destination, I meant the RequestDestination enum, not the URL, like I said.

The reason why I can't configure the loader to make this work (as far as I can tell) is that SameSite=Lax cookies never get sent in POST requests so there is no way to make that happen without changing net code.

Christian

On Tue, Sep 16, 2025 at 12:58 PM Matt Menke <mme...@chromium.org> wrote:

Renderers can request any URLs they want, that includes .well-know URLs. I had assumed you wanted to have net/ check the path because the caller didn't have privileges to configure requests itself.

If this isn't something we want renderers to do, then gating it on path doesn't make any sense - if we can't configure the URLLLoaderFactory/ResourceRequest to send lax cookies using current APIs (I'm not entirely clear on why we can't do that), then we should add a ResourceRequest::TrustedParam to do this, so that renderers can't use it.

[Matt Menke]

Sorry, missed that (And focused on your question why I was talking about URLs). If renderers can set destinations without restrictions, I don't think we want to tie sending SameSite=Lax cookies to something that could be set arbitrarily by a compromised renderer. If we do restrict destinations we accept from renderers, though, that could be an option.

Interesting that we don't send SameSite=Lax cookies on POSTs. I assume that's just on cross-origin navigations that are POSTs - subresource POSTs we presumably do, but also send SameSite=Strict cookies.

[Maksim Orlovich]

On Tue, Sep 16, 2025 at 12:17 PM Christian Biesinger <cbies...@chromium.org> wrote:

Hello net-dev,

(some context: https://github.com/w3c-fedid/FedCM/issues/587)

I had a previous discussion in chrome-security-owp about sending SameSite=Lax cookies for FedCM requests (including POST requests), and that group was satisfied with making that change.

Now I am looking at how to implement this and so I am asking this group for advice.

At a high-level, what I want is "if request->destination() == WebIdentity(), include SameSite=Lax cookies (in addition to SameSite=None)" (but do not send SameSite=Strict)

I believe this is the code to change:

https://source.chromium.org/chromium/chromium/src/+/main:net/cookies/cookie_base.cc;l=363;drc=8a5af199283ad2c25a4a0743d90d43ddc41399b4

But how should I get this information to this place?

I believe this is where the CookieOptions get created:

https://source.chromium.org/chromium/chromium/src/+/main:net/url_request/url_request_http_job.cc;l=834;drc=48d6f7175422b2c969c14258f9f8d5b196c28d18;bpv=1;bpt=1

Rather one statement above --- ComputeSameSiteContextForRequest is what's supposed to figure it out. It is not a pretty family of functions functions, and making it more complicated will not make anyone happy, but putting magical logic outside it would probably make things worse (also it has other callers).

[Christian Biesinger]

@mmenke yes, sorry, I was of course only referring to cross-site requests. It is interesting to me that compromised renderers can (apparently) set any destination they want, that seems to rather reduce the "sec" part of the "sec-fetch-dest" header. Do you know where I should look if I wanted to implement such a restriction?

@maksim If I understand you correctly, what you are suggesting is to pass in the RequestDestination to ComputeSameSiteContextForRequest and return SAME_SITE_LAX for kWebIdentity requests?

Thanks,

Christian

[Matt Menke]

CorsURLLoaderFactory::IsValidRequest() is where we do almost all our request validation. Despite the name, it's applied to all requests that don't originate within the network stack, even ones with a cors mode of none.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPTJ0XGDP6kFNW%3DPes4X4fZ%3DjxokDG%3D-Qe-rCY3dDsRa37LGEg%40mail.gmail.com.

[Christian Biesinger]

Hi Matt and Maksim,

Thanks for your help so far; https://crrev.com/c/6954729 is in the CQ to only allow the browser process to use destination==kWebIdentity. There may be other destinations that should be browser-only, but I am not familiar with them so I only did this for WebIdentity.

For the other part of changing ComputeSameSiteContextForRequest, I found the caller in https://source.chromium.org/chromium/chromium/src/+/main:net/url_request/url_request_http_job.cc;l=840?q=URLRequestHttpJob::AddCookieHeaderAndStart&ss=chromium

But it seems that URLRequest does not have access to the RequestDestination that was set on the ResourceRequest. Do you have any advice for how to access this data from URLRequestHttpJob?

Thanks,

Christian

[Matt Menke]

net/ largely is an implementation of HTTP, while RequestDestination is a web-platform concept, so doesn't really belong in net/, so we should avoid introducing net/ dependencies on the class (or moving it to net/, since net/ can't depend on services/network). I defer to folks who know more about cookies on the details, but presumably we should introduce some way for services/network to inject some hopefully more general information into the cookie code, either through a callback (in NetworkDelegate or URLRequestDelegate) or by yet another field in URLRequest.