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: Victim then visits URL, which executes The request to URL is cross-site, so it does not attach cookies URL performs a navigation to the value of the URL parameter through This triggers a request to URL, which attaches cookies, allowing an attacker to make authenticated requests from a cross-site position A similar scenario was discussed in this . Besides JavaScript redirections, other requests, such as subresource loads, could also be exploited to subvert the security assumptions granted by cookies. cookies effectively defend against certain classes of XS-Leaks attacks. However, -based attacks are still possible since cookies are attached to top-level cross-site requests. Since cookies are not attached to top-level cross-site requests, they have been deemed an effective mitigation against -based XS-Leaks. As discussed in 2.1, gadgets that allow attackers to forge same-site requests from a cross-site position can be leveraged for XS-Leaks. An example would be a page that performs a stateful subresource load, which modifies the page DOM. If an attacker opens this page through , cookies will not be attached, but following subresource loads in the new page will attach these cookies, leading to state-dependent changes to the DOM, which could be measured by the attacker (through frame counting for example). Best regards
Thanks for your well researched issue! I’ll try and address some of the points you brought up. First and foremost, SameSite is meant as only one layer in a defense in depth strategy, its design and implementation tries to balance our security and privacy goals with the realities of the web as it exists today. This ultimately means that it must be used with smart site design that leverages the other security tools and features available. differs from the original site (let’s call it a.example) navigating itself by allowing a.example to continue to hold and manipulate a reference to the new window. But, every navigation a.example makes on that reference will have an initiator of a.example (On Chrome at least, I haven’t checked other browsers, but I believe it’s true for all). This means that, as far as SameSite is concerned, an a.example window navigating itself directly or opening a new window and navigating that instead are all the same type of top-level navigation. This appears to hold true for all the examples and notes in your post. This was a purposeful decision.