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: Adds some additional notes and warnings to developers on how to more carefully use SameSite cookies.
We are reporting on the behavior of cookies on cross-site windows opened through that goes against our assumptions (implied by the current specification) on when and how cookies should be isolated. Breaking these assumptions can lead to security issues, allowing the bypass of cookies as a defense mechanism against CSRF and XS-Leak attacks. The following table shows when cookies are attached to requests associated with s and pages opened through (where :x: stands for not attached/not accessible and :whitecheckmark: for attached/accessible): The behavior of cookies regarding page reloads for pages opened through from a cross-site position is evident from the : Currently, the specification mandates blocking cookies on user-initiated page reloads but not on reloads performed through JavaScript. We think that cookies should also be blocked in this scenario, as this interaction between JavaScript navigations and cookies allows attackers to bypass the restrictions imposed by (see 2.1). Additionally, we verified that cookies, even when not sent in the top-level request that loads a page, are still attached to requests that load subresources for that page. This behavior is not explicitly defined in the specification. However, its counterpart (setting a cookie) is defined as follows: Although these requests are not cross-site, they are performed implicitly by a page navigated from a cross-site context, effectively enabling an attacker to perform authenticated cross-site requests (see 2.1), or cookie tossing attacks. Following this argument, when considering that user-initiated page reloads are deemed cross-site and therefore do not attach cookies, it seems reasonable to assume both JavaScript navigations and subresource loads should also not attach cookies, as they are also transparent to the user. It is possible to abuse the previously described behavior to bypass CSRF protections An attacker can forge same-site requests starting from a cross-site position by abusing gadgets that result in secondary same-site requests. An example of one of these gadgets is a JavaScript-based redirect that performs a redirection using attacker-controlled data. Here is a possible attack flow: Victim visits URL, setting the cookie cookie for domain .