In my experience until developers have to work extremely hard to create a security bug, disabling numerous defaults, it is never going to be a "solved" problem.
Prepared statements fix SQLi. Encoding HTML entities on output fixes XSS. Etc. etc. Even SPA frameworks that default to encoding entities get hit with XSS.
Unless it is completely stamped out by default or simply no longer possible I encourage solutions like this. And this is mostly just an XSS problem, but XSS that leverages simple CSRF vulnerable end points is still a problem. To be safer you now need 3 flags on a cookie (HttpOnly, secure, and SameSite).
This is a pain for developers and almost ensures weird edge case CSRF type vulns will still creep up on occasion. Similar to how memory corruption mitigations often force an exploiter to combine multiple vulns to achieve the effect of one old school vuln, this raises the bar, but does not eliminate the possibility.
No-one is going to set a strict SameSite cookie, it just breaks too much, it's the same level of hubris as thinking developers are going to care about CSP. It just breaks too much shit.
So we're left with Lax SameSite cookies, which is pretty much the same as what existing web frameworks do.
The best you can say is that this is less likely to have bugs in the implementation.
I'd say surely banks will use this for their online banking systems.
Then I wonder, because of some of the delightful vulnerabilities I've heard about.
So I'll just say banks certainly should use Strict SameSite cookies, and in fact they seem designed to suit banking workloads (especially as banks don't usually offer persistent logins, because that's too dangerous).
Prepared statements fix SQLi. Encoding HTML entities on output fixes XSS. Etc. etc. Even SPA frameworks that default to encoding entities get hit with XSS.
Unless it is completely stamped out by default or simply no longer possible I encourage solutions like this. And this is mostly just an XSS problem, but XSS that leverages simple CSRF vulnerable end points is still a problem. To be safer you now need 3 flags on a cookie (HttpOnly, secure, and SameSite).
This is a pain for developers and almost ensures weird edge case CSRF type vulns will still creep up on occasion. Similar to how memory corruption mitigations often force an exploiter to combine multiple vulns to achieve the effect of one old school vuln, this raises the bar, but does not eliminate the possibility.