Why wouldn't a site's cookies be sent in this scenario?

Question

I'm reading an article on Okta's engineering blog, which contains the following paragraph:

Some of the disadvantages of cookies include:

Cross-site request forgery attacks (XSRF or CSRF): CSRF attacks are only possible with cookie-based session handling. The SameSite attribute allows you to decide whether cookies should be sent to third-party apps using the Strict or Lax settings. A strict setting can prevent CSRF attacks, but it can also contribute to a poor browser experience for the user. For example, say your site uses a cookie named tutorials_shown to determine whether a user has already seen specific tutorials in order to show them new ones every time they visit. If SameSite is set to Strict and someone follows a link to your site, the cookie will not be sent on that first request, and previously viewed tutorials will be shown. This creates a less personalized user experience.

I get why "previously viewed tutorials will be shown" in this scenario, but I don't get why "the cookie will not be sent on that first request". If I'm on site A, which contains a link to site B (for which I currently have cookies stored in my browser), I'm confused as to why those cookies wouldn't be sent as part of the request when I click the link to site B.

As long as site A can't inspect the request that I make to site B, it doesn't seem like a security risk to send the cookies on every request, including that 1st one. So does this imply that site A does in fact have the ability to inspect that request, including the cookie data?

Answer 1

The "Strict" mode for cookies' samesite flag prevents the cookie from being sent on any request that originates outside the current site (including from things like "user clicked a link in another program" or "user typed the URL in the bar". This is rarely used, because it interferes with user experience. However, it is slightly more secure. The risk is if a site is vulnerable to CSRF from a simple GET request, in which case a link from another app (such as an email or chat client, or a document) could trigger the exploit. GET requests aren't supposed to have such effects, but there's nothing enforcing that and in practice, lots of web apps do allow sensitive actions with just a GET request. If such a site uses cookie-based authorization, CSRF attacks are possible even with samesite in its usual "lax" mode, so the "strict" mode exists to prevent such attacks.

As a side note, be aware that samesite protection is not complete, even in strict mode. The definition of "site" is broader than you might expect, especially if you're familiar with "origins" and the same-origin policy. Every different site is also a different origin, but it's possible for different origins to be the same site (typically because of subdomains, though different ports and protocols can also be the same site). So if there's any potentially-malicious code anywhere on your domain (including subdomains) / host, under any port or protocol, even if it's client-only code without server control, you can't count on the samesite flag to prevent CSRF. Fortunately, there are many other ways (which are outside the scope of this answer).