I'm trying to understand if Cross-Site Request Forgery (CSRF) can be completely prevented by using a strict SameSite cookie for authentication. I've heard that while this might be effective, it could also negatively impact user experience since the website might not recognize users when they navigate here from other sites.
What if we use two types of tokens: one lax for GET requests (which don't change anything) and one strict for POST, PATCH, PUT, and DELETE requests? Would that effectively protect against CSRF?
2 Answers
Honestly, I think cookies should just be banned for security reasons. It's a risky business.
Yes, the dual cookie approach is a solid strategy! You can use SameSite=Strict for your authentication token in state-changing requests, while the Lax setting works for read-only actions. This is a modern evolution of the double-submit pattern.
Just a heads-up, though: if a user arrives at your site from an external link and tries to submit a form right away (like hitting a direct link to an action page), the Strict cookie won't be sent during that initial navigation. Most apps don't encounter this, but it's something to consider if yours does.
Additionally, keep in mind that SameSite alone doesn't guard against attacks from untrusted subdomains under the same registrable domain. However, for most setups, your method is reliable!
Come on, you can't just say that without explaining why! Not understanding cookies and their role in security doesn't help.