I ran across this OWASP paper and was frankly confused. I thought this pattern was still one of the cornerstone strategies against CSRF but the paper seems to say it's broken. Should this pattern still be used?
https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf
Double-submit cookies was always a relatively weak CSRF protection, at least as typically implemented. Any attacker who can set a cookie - either via a cookie injection vulnerability in the app or via man-in-the-middle (MitM) attack - can defeat the typical implementation of double-submit cookies; this has been known for many years. It also requires that the CSRF-protection cookie be Secure-flagged, or a MitM attacker can usually steal it.
There is actually at least one thing that changed in recent years to make double-submit cookies less insecure than before. HSTS (HTTP Strict Transport Security) is a big help; with every major browser supporting HSTS and TLS performance becoming essentially a non-issue, there's less excuse than ever for not using HSTS. HSTS prevents most ways an attacker could steal or set cookies. You can also use the SameSite flag on your session cookies (with most browsers) to block most CSRF attacks; although not directly related to double-submit cookies, these techniques can be combined for additional defense in depth.
If you want to use double-submit cookies for CSRF protection, I recommend cryptographically tying the anti-CSRF token to the session token. A really simple way to do this is just to make your anti-CSRF token (sent in the request body) be an HMAC of the session token (using a secret key stored only on the server or in a hardware security module). This avoids even setting a second cookie specifically for CSRF protection, but an attacker cannot meaningfully spoof the token because changing the session cookie will break the user out of their own session. Alternatively, you can set an anti-CSRF cookie, and then have the token value be an HMAC of the cookie and some user identity data (such as a username or user ID); this means that your users will not need to update their anti-CSRF tokens every time their session token changes (which might be frequent, if using a short-lived JWT or similar) but an attacker won't be able to log in themselves, find a valid CSRF-cookie + CSRF-token combo, and plant those values in a victim's browser session (or rather, it won't work if they do, because it will be for the wrong user). Additionally, use HSTS (on all sites, including subdomains, and add it to the preload list) and, if you can, also use at least the "lax" SameSite flag. Neither of these will protect users on IE10- (or similarly old browsers), but you probably don't have many such users.
