In my experience, even SameSite None is not sufficient to use cookies in cross-site iframes. Safari doesn't allow those cookies to be sent unless you visit the site directly first. I've heard movements for Firefox and/or Chrome having similar behavior, but I haven't been working with iframes recently enough to know the current state of that.
You are correct about this and I've been bitten by this in the past. (Un)fortunately, I am currently involved with enterprise™ projects where Safari is a distant afterthought.
There certainly are legitimate use-cases. I like Jacob's following suggestion for a check that might help alleviate a misconfiguration concern, if they did change SameSite to none without activating CSRF protection. If it were possible to identify other places where there might be a sharp-edge misconfiguration because of the cross-domain difference of meaning between samesite and what CSRF needs, that could be good as well. And those checks would, I think, be worthwhile even without changing the default, since they are currently possible configurations.
If CSRF is turned off by default, adding such a check would be a good idea. It should definitely check for `SESSION_COOKIE_SAMESITE`'s value, since the session cookie is usually the one that needs protection from CSRF, but I haven't thought deeply about theotherthe cookies. This could have implications regarding `HttpResponse.set_cookie`, since it can't be checked by a system check.
I think what we want to weigh is whether the footgun of *not* having CSRF by default is bigger than the significant complexity overhead of managing the CSRF projection in a new project. It's marking all views, adding tags to all form templates, and I think it can be easy to underestimate the attention it requires. If we can eliminate this overhead, especially for beginners starting out with Django and web development, that sounds like a great benefit. Lowering the barrier to entry is worth a lot.
I mostly wanted to argue against the removal of the current CSRF machinery altogether, since it is still necessary for certain use cases.
Removing it from the default template is a harder question. I completely understand the complexity point, since I've lost track of how many times I've had to explain what a CSRF error is and why you should care. Still, I'm not sure if removing it from the default template would be OK, since it would trade off security for convenience (even if only for marginal cases).
Best, Stratos -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/A1CC86D7-24E6-457F-9B62-3FD4C82A775C%40gmail.com.
