Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that.
Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.
I'm not sure I'm understanding your solution
If the domain name is in the cookie value then that can't be used when submit another request from another domain. Yes you can configure the dns to bypass that, but at that point it is also pointless for CSRF.
Not to be rude, but from your comments you don't appear to understand what the CSRF vulnerability actually is, nor how attackers make use of it.
Cookies can still only be sent to the site that originally wrote them, and they can only be read by the originating site, and this was always the case. The problem, though, is that a Bad Guy site could submit a form post to Vulnerable Site, and originally the browser would still send any cookies of Vulnerable Site with the request. Your comment about "if the domain name is in the cookie value" doesn't change this and the problem still exists. "Yes you can configure the dns to bypass that" also doesn't make any sense in this context. The issue is that if a user is logged into Vulnerable Site, and can be somehow convinced to visit Bad Guy site, then Bad Guy site can then take an action as the logged user of Vulnerable Site, without the user's consent.
Given what was written, I'm not quite sure the author does either.
> Just had the sitename put into the value of the cookie since, and never really needed to think about that.
How would that help? This doesn't seem like a solution to the CSRF problem