Search code examples
httpcookiescsrfsame-origin-policysetcookie

Lax vs Strict for Set-Cookie HTTP header and CSRF

I was just reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie:

Lax: The cookie is not sent on cross-site requests, such as calls to load images or frames, but is sent when a user is navigating to the origin site from an external site (e.g. if following a link). This is the default behavior if the SameSite attribute is not specified.

If this is the default, then doesn't this mean CSRF attacks can't happen? If someone loads a malicious website that runs Javascript in the background to make a simple POST request to a website the victim is currently logged into, then the default behaviour is that the cookie won't be sent, right?

Also, why would someone choose to use Strict over Lax? Why would you ever want to prevent a user's browser sending a cookie to the origin website when navigating to that website, which is what Strict does?

Solution

  • CSRF attacks are still possible when SameSite is Lax. It prevents the cross-site POST attack you mentioned, but if a website triggers an unsafe operation with a GET request then it would still be possible. For example, many sites currently trigger a logout with a GET request, so it would be trivial for an attacker to log a user out of their session.

    The standard addresses this directly:

    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. Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in section 5.2.1), which is only a speedbump along the road to exploitation.

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

    Given that, the reason why someone would use Strict is straightforward: it prevents a broader class of CSRF attacks. There's a tradeoff, of course, since it prevents some ways of using your site, but if those use cases aren't important to you then the tradeoff might be justified.