ASP.NET will soon begin reflecting Google's decision to default cookies to SameSite="strict" in a defense against CSRF attacks:


This means that if I own foo.com, any logged-in users who are directed to foo.com from off-site will consume the content as if they are not logged in, as the browser will refuse to send the forms authentication headers with the request by default.

This is a poor user experience, and I'm tempted to simply specify SameSite="Lax" to ensure that users are not surprised by this behavior.

Is there any way to have my cake and eat it too, in this scenario?

  • Help me understand, why would there be a problem specifying SameSite="lax", when that's exactly what you want? Just because the default is changing, it isn't necessarily forcing a "strict" state. (Did I misunderstand your question?) – s h a a n Oct 27 '19 at 17:19
  • 2
    From the link it seems that google is changing the default to lax, not strict. A default strict seems like it would break quite a bit so I'm not sure that's going to happen. – tim Oct 27 '19 at 17:29
  • What do you mean by "forms authentication headers"? – curiousguy Oct 28 '19 at 2:51
  • @tim Strict is anti UI and to me just inane. It means that landing on a page would have a effect and then doing ^L <enter> (page reload from URL) another. And then I don't know what ^R would do (the semantic diff between ^L <enter> and ^R is interesting). – curiousguy Oct 28 '19 at 2:53

Short answer: No, there's no way to have the benefit of Strict SameSite without the drawbacks of Strict SameSite. However, you can get most of the benefits (and fewer drawbacks) by using Lax SameSite.

I think you quite badly misread that article you linked. Google is not, and has no plans to, change the default SameSite behavior to Strict. All they are doing is changing the default to "Lax" and adding "None" as a new option to override this default. ASP.NET is making no changes except adding the None to the enum values.

The concern is that, if you send SameSite=None to a browser that doesn't yet know about this value, it will interpret it as SameSite=Strict because that's what the standard says to do when the value isn't recognized. Therefore, IF and ONLY IF you DON'T want to use SameSite at all, you will need to do user-agent sniffing to determine "this browser still defaults to no SameSite and will freak if I say SameSite=None" vs. "this browser defaults to lax SameSite and I need to tell it to not do that".

If you expect top-level navigation from other sites to yours, but do not expect to need cross-site authenticated requests other than top-level GET navigation, then you should already be setting SameSite=Lax, and this change (neither Google's change nor ASP.NET's change) has no impact on you.

If you are already using Lax SameSite, you literally don't need to do anything at all (I guess you could save a few bytes by sniffing new Chrome builds and not sending the now-redundant header, but it's probably not worth the effort).

If you actually want to use Strict SameSite, do it exactly the way you would today; nothing has changed there either.

As a final word of advice, bear in mind that there are still a lot of people using outdated browsers that don't support SameSite at all. It's potentially valuable as a defense-in-depth measure against CSRF, the same way CSP is a defense-in-depth against XSS, but you still need some other anti-CSRF mechanism for anybody on browsers that don't support SameSite, unless you block all such browsers from signing in at all.

| improve this answer | |
  • Even if SameSite is supported, you'd better check whether SameSite for the browser means "same as your site" (controlled by you), according to your DNS naming hierarchy. Beware of subdomains that are delegated to someone else. – curiousguy Oct 28 '19 at 2:51
  • @curiousguy The existing difference in cookie same-origin policy vs. everything else SOP is confusing, but I'm pretty sure that, for SameSite in particular, it uses the common meaning of "Origin" used by things like XHR and so forth, which considers subdomains (and parent domains) to be of a different origin/"Site". Something I should verify, though. – CBHacking Oct 28 '19 at 5:16
  • You should indeed. Cookies confusingly allow sharing with subdomains and parents, up to the mysterious notion of "registered domain". It's a complicated story. And ppl can disagree about whether sharing would be allowed, and over what SameSite would do. Cookies were never aligned with JS. – curiousguy Oct 28 '19 at 5:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.