I did a fair bit of reading on CSRF. While we should always try and use SameSite attribute for cookies, it is not a fool-proof method for protecting against CSRF. CSRF token should still be used. The SameSite=Strict will only work for browsers that implement this feature. If a user uses a browser which does not support it, they can be vulnerable. Additionally there are ways to bypass this feature even for browsers supporting SameSite attribute.
It is important to note that this attribute should be implemented as an additional layer defense in depth concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the following section. This attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way.
If you are using REST APIs to secure content and not sending it back as part of a SSR. Then those bypasses don't apply. Since it isn't secure to send content back as part of page navigation anyway. CSRF can entirely be replaced by SameSite.
We're a place where coders share, stay up-to-date and grow their careers.
I did a fair bit of reading on CSRF. While we should always try and use
SameSiteattribute for cookies, it is not a fool-proof method for protecting against CSRF. CSRF token should still be used. TheSameSite=Strictwill only work for browsers that implement this feature. If a user uses a browser which does not support it, they can be vulnerable. Additionally there are ways to bypass this feature even for browsers supportingSameSiteattribute.Quoting from CSRF sameSite:
If you are using REST APIs to secure content and not sending it back as part of a SSR. Then those bypasses don't apply. Since it isn't secure to send content back as part of page navigation anyway. CSRF can entirely be replaced by
SameSite.