flawopen.com/CSRF/SameSite cookies
It closes most of the gap for modern browsers, but it's not a complete substitute — it depends entirely on cookie-based session auth, and edge cases (older browsers, certain navigation patterns) still exist. Most security guidance recommends both as defense-in-depth.
A SameSite=Strict cookie is never sent on a cross-site request — including the classic CSRF pattern of an attacker's page auto-submitting a form to your site. This directly neutralizes the mechanism CSRF depends on: the browser silently attaching your session cookie to a forged request originating elsewhere.
If your app authenticates via a bearer token stored in a header (not a cookie), SameSite is irrelevant — the browser doesn't attach headers the way it attaches cookies, so this specific defense doesn't apply to that authentication model at all.
Only Strict blocks cookies on every cross-site request; Lax (many browsers' default when unspecified) still sends cookies for top-level GET navigations, which can matter if a state-changing action is ever reachable via GET.
SameSite is enforced by the browser — a client that doesn't support or respect the attribute provides no protection, which is part of why defense-in-depth (CSRF tokens as a backstop) is still commonly recommended.
See the dedicated page on this — short answer: state-changing actions should never be reachable via GET in the first place, which sidesteps the question.