According to this ietf doc there are two vulnerabilities to samesite cookies:

  1. Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in section 2.1), which is only a speedbump along the road to exploitation.

  2. Features like <link rel='prerender'> [prerendering] can be exploited to create "same-site" requests without the risk of user detection.

I've found that the prerendering bug seems to have been fixed on chromium in 2019.

I really don't know how to recreate a scenario as they mention in 1.

I've read a lot of people say that samesite is enough to protect against csrf attacks, but I've not seen anyone address this document which is mentioned in this OWASP cheat sheet. They say that because of these vulnerabilities, samesite is not enough and they still recommend csrf tokens.

1 Answer 1


Yes, the "pop-up window or top-level navigation" one is still a threat because it's inherent to the way that samesite=lax works. However, in practice it's not very much of a threat at all, because it's unlikely to be exploited. Obviously you can do it if the attacker already has code execution within the victim's site via e.g. XSS (in which case it's game over; no anti-CSRF protection can save you now because the requests are literally coming from the same site, via a malicious script running on that site). The other option requires that the malicious request be possible using a "safe" HTTP method (GET or HEAD). Such requests should never be state-changing (although in practice people break this rule a lot, especially with things like log-out links).

You can also sometimes work around SameSite by abusing redirect functionality built into sites (especially login pages), where the browser might treat the redirect as a same-site request even if it is downstream of a cross-site request. Furthermore, prerendering isn't only relevant to <link> tags, and sometimes is carried out by software technically outside of the browser, such as antimalware software or a pre-fetching proxy, either of which might in theory send cookies (to ensure the page they pre-fetch is correct) without being aware of SameSite implications.

However, the big weakness of SameSite is in what is considered a "site". The short version is that different ports and different subdomains are usually still the same site, such that even a samesite=strict cookie set for foo.site.com will still be sent on requests from bar.site.com, and a cookie set for https://othersite.com will also be sent on requests originating from https://othersite.com:8443, which might be a totally different and possibly less-trustworthy server. The long answer involves the Public Suffix List and has been talked about in lots of other SameSite-related discussions on this board.

  • Hi. Thanks for the detailed answer. I think I misunderstood that these two vulnerabilities were applicable to SameSite generally, which is why I was so confused. But from what I understand now, these are particularly issues with samesite=Lax, right? I appreciate the discussion about what is considered a site, which seems to be the larger issue here.
    – jacob
    Jul 10, 2022 at 16:22
  • 1
    Yeah, that's specifically concerning the Lax mode. From the doc: Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like "POST"), but does not offer a robust defense against CSRF as a general category of attack: [#1] [#2] where #1 and #2 are the things you quoted. OTOH, almost everybody uses Lax (strict is too inconvenient in many cases) so it's very valid to consider the gaps in Lax when considering what samesite does or doesn't handle.
    – CBHacking
    Jul 11, 2022 at 1:08
  • @CBHacking regarding the popup window attack, given the XSS caveat is a fair summary that this is only an actual vulnerability if you have state-changing endpoints which change state? Mar 8, 2023 at 22:04
  • 1
    @ChaseMedallion State-changing endpoints reachable via GET requests, yes. For example, if you popup/navigate to example.com/logout, on many sites that will log out the current user even though a GET request shouldn't be state-changing.
    – CBHacking
    Mar 9, 2023 at 8:46
  • @CBHacking thanks & makes sense. Out of curiosity, is being able to attack the /logout link via CSRF of any use to the attacker (I realize that was just an example, but since it is always used as the example of state-changing GET I am curious)? Seems like an annoyance at best. Mar 12, 2023 at 0:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .