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: We wanted to allow the site to be able to operate specific “landing pages” in order to allow third-party entities (maybe a sign in flow or payment processor) to navigate the user back and then the landing page could refresh to allow access to cookies in order to complete the process. Since the reload must be explicitly initiated by the page it would require the site developer to “opt-in” to the behavior and hopefully design the landing page with that behavior in mind. Conversely, we disallowed user initiated reloads because that doesn’t show an intention on the site’s behalf that it wants or needs cookies following that cross-site navigation. Users have been taught over the years to try reloading if a page looks broken, something that could occur if cookies aren’t present. Continuing to block cookies helps prevent users from inadvertently weakening their own security. That’s expected and intended. Samesite operates on a per request basis (or on a per JS call basis) so all requests, sub-resource or otherwise, are subject to the same rules. See . The spec assumes that since the page loading the same-site resources is in control of what it loads, it shouldn’t load anything that makes harmful changes. You’re correct that if a site exposes an API like you’ve given in 2.1 then it’s possible to give an attacker control + access to SameSite cookies. But to me it appears that the gadget is the footgun and I’m not sure how/if SameSite should solve this. Allowing any cross-site entity to make requests as yourself is a dangerous tool! I mentioned above that pages are in control of what they load and as long as they only load safe resources that they’re expecting they should be fine, but if you have any examples to the contrary I’m very interested in hearing about them. Going back to how s are basically the same as any other top-level navigation, this is the intended behavior. Lax cookies shouldn’t be used for anything that can allow changes to anything important. Agreed, it’s definitely possible to leak state this way. I’m not familiar with the reasoning with why the single-origin policy allows references to read , but I’m sure the spec writers had a good reason. Hope that helped clear things up, let me know if you have any other questions or concerns.
Hi NAME thanks (as usual) for the kind and thorough response!