Repository navigation
Why must SameSite=none? #587
Description
I've searched the repo and read through #212 and #248 but I'm still confused about the SameSite=none requirement.
LastLogin currently uses SameSite=lax for all cookies. Changing to none potentially opens up several vulnerabilities that need to be carefully considered. I get some protection from CORS, but there are so many edge cases that things can slip through with "simple requests" etc. I could also add a tiny sentinel cookie set with SameSite=lax and then require both cookies for all endpoints except FedCM, but again that requires me to get it right everywhere, which is dangerous.
Overall, why is this necessary in the first place? It seems like a very intentional decision, but I haven't found a clear explanation yet. As @samuelgoto mentions here it seems to me that FedCM already is secure enough to be trusted sending lax cookies.
Activity
sebadob commentedon May 20, 2024
That's a big pain point for me as well and I would actually never deploy something to prod with this setting.
I think the browser should just sent even host only cookies to the IdP in that case and since it's behind the scenes anyway, I don't see an issue with doing that. The other way around, setting
SameSite=Noneis something I would never do these days, as it would be like 3 steps back in terms of security.anderspitman commentedon May 20, 2024
@samuelgoto any additional info on this?
samuelgoto commentedon May 20, 2024
We are working with our privacy and security reviewers to figure out what we can do about this. Will report back.
samuelgoto commentedon May 20, 2024
@johannhof I hear that this is working as intended. Can you help us understand why
SameSite=Noneis required andSameSite=Laxwouldn't suffice?cbiesinger commentedon May 21, 2024
@bvandersloot-mozilla @annevk fyi
johannhof commentedon May 21, 2024
I think I understand your concern and that you consider requests initiated by FedCM to meet a higher bar than "regular" cross-site fetch requests, however, let's look at the available options and their current definitions:
Of course, we can revisit and change things if they don't make sense. This was discussed in #248 and the suggestion back then was to add a
SameSite=Federatedattribute, which probably doesn't work due to backwards/cross-browser compat issues.We could consider broadening the definition of
SameSite=Laxto cover things like browser-UI triggered requests, but we'd need to make sure that we're not inadvertently opening up an attack surface for anyone. If you were previously using the above definition to protect your endpoints you may be surprised to learn that there's a new cross-site way to triggerSameSite=Laxcookies.cc @arturjanc for thoughts
johannhof commentedon May 21, 2024
@DCtheTall FYI ^
anderspitman commentedon May 21, 2024
Thanks @johannhof.
I think the problem is that FedCM requests feel like a new thing. Is there any precedent for requests that are sent by the browser but which the origin has no direct control over the method, content, or response (only the URI can be controlled by the RP)?
I can see why you technically consider them to be cross-site requests since they wouldn't be fired without visiting an RP, but do they really fit the description of what we've always considered cross-site on the web up to this point? The term is generally used in conversations involving CSRF security concerns and privacy, and I haven't been able to come up with any scenarios where FedCM requests would introduce a security vulnerability (caveat: I am not a security expert). The endpoints are highly prescribed and the results aren't directly accessible to the RP.
On the flip side, forcing all cookies to be SameSite=none for FedCM introduces real, tangible security issues.
johannhof commentedon May 21, 2024
Yeah, I understand the negative security implications this would cause for IdPs in the mid term (that is, until 3rd party cookies are blocked by default without workarounds in all browsers) and I agree it's not a great outcome.
I'm honestly torn on this issue. I'd love to hear from some of the tagged folks (@arturjanc @annevk @bvandersloot-mozilla) regarding their thoughts on a possible inclusion of FedCM requests in
SameSite=Laxrules.sebadob commentedon May 21, 2024
I think it would make a lot of sense to even be able to set host only cookies, even with
__Host-*and have the FedCM send them anyway, even it is is technically cross origin. It would not be a security issue or against any "rules", because the FedCM API operates behind the scenes from inside the browser and not on the user-facing side, and can be trusted.On the other hand, if we would set host only or samesite cookies, they are restricted to the IdPs domain / host and would not leak anywhere else, even when the FedCM is not used.
johannhof commentedon May 22, 2024
Chatted with @arturjanc about this offline, and the fact that all these endpoints have to be pre-registered by the IdP in a config file makes us think that carving this out as a new instance where
SameSite=Laxcookies are sent might be acceptable. I would also be interested in @mikewest's thoughts on that idea.@sebadob relaxing cross-origin restrictions feels like a fundamentally different suggestion and much less likely to happen, as that is a concern of not leaking additional data to the IdP endpoint (which could also be a risk to that endpoint itself, if there are ways for subdomains to set the cookies it is looking for). This is all very hard to reason about and it's important that we don't pull the rug on security concepts people are relying on.
sebadob commentedon May 22, 2024
@johannhof don't get me wrong, I would never want this to be a global change, only for these specific endpoints where we actually need the cookies during the FedCM flow. Basically like you suggested.
The
SameSiteattribute is one of the best defenses we have against CSRF attacks. I would never want to give that up just to support some new auth flow, even if it provides a really nice UX, and rather stick to OAuth / OIDC on its own.annevk commentedon May 22, 2024
I don't understand the discussion about
__Host-cookies. That's a syntactic mechanism to enforce a couple of attributes of a cookie. It's unrelated toSameSiteand can always be used. Are you suggesting to change the semantics in some way? If so, please explain by way of an example involving the multiple parties. But also, if it's not related toSameSiteit should probably be its own issue.Creating a new avenue for
SameSite=Laxexploits makes me rather nervous. I guess to some extent the question here is whether the "speedbumps" for attackers as 6265bis puts it are equivalent.(Also, you never get protection from CORS. The protection is from the same-origin policy. CORS pokes holes in that.)
sebadob commentedon May 22, 2024
Sorry the
__Host-does not belong here, that's true, my bad.Edit:
The main question was actually only, why the FedCM wants
SameSite=Nonecookies whenLaxshould not be an issue.anderspitman commentedon May 22, 2024
I appreciate the time being taken to seriously consider this concern. Honestly the situation makes me a bit uneasy. Just because it seems safer to relax SameSite=lax than to require SameSite=none doesn't necessarily mean that's the case. My instincts tell me this should be treated as a new thing. The SameSite=federated suggestion should work. But if people who know more about security than me (not a high bar) sign off on SameSite=lax being relaxed, I won't complain.
58 remaining items
annevk commentedon Sep 12, 2025
Presumably you'd include the context in the request?
Bug 1906982 [wpt PR 47065] - [FedCM] Send SameSite=Lax cookies, in ad…
hlflanagan commentedon Oct 28, 2025
Discussed 28 October 2025
Send SameSite=Lax cookies for FedCM requests
cbiesinger commentedon Oct 31, 2025
Starting in tomorrow's Chrome Canary, you can test this using
--enable-features=SendSameSiteLaxForFedCM. Sorry, this is not listed in chrome://flags, but will work from the commandlineannevk commentedon Nov 3, 2025
The minutes suggest I'm open to this change, which is true, but I did stipulate some preconditions, no?
cbiesinger commentedon Nov 3, 2025
I apologize if I misrepresented your position. I am aware of the preconditions and sending those emails is still on my TODO list.
cbiesinger commentedon Nov 4, 2025
I have filed httpwg/http-extensions#3323 and sent https://lists.w3.org/Archives/Public/ietf-http-wg/2025OctDec/0156.html
Send SameSite=Lax cookies for FedCM requests
cbiesinger commentedon Dec 9, 2025
@anderspitman / others, I am still interested in hearing if this is working for you!
anderspitman commentedon Dec 9, 2025
Sorry @cbiesinger busy times for me, but I'll see if I can carve out a couple hours to play with this in the next 2 weeks. Are there any looming deadlines on your end where it would be nice to get this tested?
cbiesinger commentedon Dec 10, 2025
Thanks @anderspitman . No particular timeline, I just don't want to start going through the shipping process before someone has actually tried this out.
will-bartlett commentedon May 10, 2026
I stumbled across this today. +1 for this being a problem. Big picture - SameSite is used to protect websites against unexpected requests. FedCM requests are never unexpected, because the browser will only make them cross origin if the origin has configured a well known file.