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: I did a bit of additional investigation and found some discussions that we missed before opening the issue: URL and URL As far as I understood, the current behavior concerning page reloads has been defined only recently (2021). Before that, different browser vendors had . Even nowadays, browsers do not seem to fully agree on the intended behavior, or at least Firefox is inconsistent with Chrome's behavior since it does not attach SameSite=strict cookies after a call to . Some confusion on this matter is justifiable. :) I now see the rationale behind the design that enables specific pages to opt-in to SameSite=strict cookies upon a self-initiated reload. I always thought SameSite=lax cookies ensured compatibility with SSOs and payment flows, as lax cookies are attached to top-level navigations. But this "strict + reload hack" (so to say) puts the webpage in control instead of attaching cookies to all cross-site top-level requests. The downside of this behavior, as discussed, is that JS-based open redirectors become a gadget for bypassing SameSite=strict cookies. I'm not sure if the benefits outweigh the risks, but probably, the spec would benefit from a more explicit discussion of this trade-off. Concerning subresource loading, I would argue that in general this is not a valid assumption. In principle, here we have an untrusted context (the cross-site page opened via ) that automatically loads authenticated resources. This is somehow the dual of SRI, CSP, mixed content, and other security mechanisms that prevent a trusted context from loading untrusted resources that an attacker could abuse. We have not measured the prevalence of security issues caused by this behavior in the wild (i.e., xs-leaks introduced by an authenticated subresource being loaded), but I would expect a non-negligible number of affected instances. The current behavior surprised me, and it is possible that developers who care about protecting from xs-leaks are also unaware of the potential risks. For instance, the states that: citing only other reasons (e.g., the 2 minutes exception rule) as major limitations of SameSite cookies. To conclude, we just wanted to discuss this issue after encountering a behavior that diverges from our mental model of SameSite cookies and that we could not entirely justify it after reading the spec.