However, I'm not sure I see any security improvements for applications that already prevent CSRF.
However, I'm not sure I see any security improvements for applications that already prevent CSRF.
For a time being, it won't - unless you intend to only provide CSRF protection for the browsers that support this extension (and can server even detect whenever the UA is capable or not?). I think for at least a few years, Cookie+POST data is the only reliable option.
Not entirely. If you're willing to set headers you can do so as a trivial anti-CSRF measure. Just setting a header like "X-Totes-Not-CSRF" would suffice as CORS will prevent arbitrary sites from setting such a header. Its value does not matter.
Reference: https://docs.angularjs.org/api/ng/service/$http
This is an effective approach because unless an attacker has already compromised the relevant cookie, they will be unable to spoof the X-XSRF-TOKEN header in a cross-origin request. On the server-side, you just need to validate that (a) the X-XSRF-TOKEN header was sent and (b) it contains the expected value for each HTTP request received.