Code change:
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other <del> attack vectors such as cross-site scripting. </del> <ins> attack vectors such as cross-site scripting or abuse of page redirections. Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Related discussion:
text: As for JS-initiated reloads, if the behavior is here to stay, I think the spec could mention these limitations more explicitly to prevent developers from building their applications based on wrong assumptions. Thanks again for the discussion! Marco
Hi NAME As you found in those discussions, reload behavior wasn’t well aligned previously and I’m not sure how purposeful each UA’s behavior was at the time. I know Firefox has a number of SameSite related behaviors behind default disabled configs, this could be as well. I don’t have easy access to Firefox at the moment but I believe the nightly builds have these flags enabled. What happens if you try testing on a nightly build? SameSite=Lax is useful for flows that use top-level navigation, but if a flow is happening in an iframe then SameSite=Lax cookies would be blocked. The reload technique enables these iframe based flows to function. The issue here is that a page may still load sub-resources that require SameSite=Strict auth cookies even if the initial request didn’t include those auth cookies? Plainly, any site that allows unauthenticated access to a page which loads authenticated sub-resources is incorrectly using SameSite. Sites should return a 401 error, or some other denial, if the initial request does not include the appropriate cookies. Sadly though, I agree with you that there are probably sites that do not. Just to confirm, the behavior you’re talking about are: URL navigations are not as restrictive as iframe navigations. Non-user controlled reloads allow cookies Sub-resource requests send SameSite cookies Redirect gadgets allow access to SameSite cookies Did I miss any? What do you mean by “these limitations”? Are you referring to the redirect gadget?
Any remaining comments/concerns before I close?
Hi NAME Sorry, I missed your earlier reply in October, and I'm just now seeing it. Thanks for the ping. I tried Firefox 123.0.1 (stable) and Firefox 125.0a1 (nightly), and they behave the same way. SameSite cookies are not attached to requests initiated via , but they are attached to requests caused by . Chrome sends the cookie in both cases. Indeed. While open redirectors and script gadgets are known to carry their problems, I am concerned about issues enabled by authenticated subresource requests, as they are less known to web developers. I don't think so.