Cookie-based CSRF protection (typically called the "double-submit cookie" pattern, because the same value is submitted in the request body and in a cookie) is not a great way to prevent CSRF. It's vulnerable to any attack that allows planting or manipulating the victim's cookies, and cookies have a weird security model that is looser than the same-origin policy which underlies most other web security. However, if you want to use it in this scenario anyhow, you'll simply have to send the anti-CSRF token in the response body as well as in the cookie. There are ways to do this, even cross-origin. If you're loading HTML pages directly (possibly with HTML form elements), you can embed the value in a hidden element. If you're loading page data into templates or constructing the DOM on the client, you are presumably already using CORS (or, $DEITY help you, JSONP) and can return the anti-CSRF token in the JSON (or whatever) message. You can also have an API specifically for getting the current anti-CSRF token value. All of this is compatible with preserving the statelessness of double-submit cookies; the server just returns whatever value was in the cookie it received, or generates a new value and both sets it as a cookie and returns it in the response.
If you want to go with better options, there are a few of them. Presumably you're using cookies for session tokens already (otherwise you're almost certainly already immune to CSRF); you can just make the anti-CSRF token be a hash or HMAC of the session token (assuming it doesn't change too often), rather than setting another cookie and/or requiring the client to see and parse cookies in JS. Alternatively, since you're probably already using CORS, you can just require that all state-changing requests be non-simple requests that require CORS preflights (any request that an HTML form couldn't make requires a preflight, e.g. use a verb other than GET/POST/HEAD, use a content type such as "application/json" and enforce this on the server, use any custom header even if the value is a constant) and make sure your CORS configuration doesn't allow any origins other than the trusted frontends. You could also stop using cookies for session tokens, and switch entirely to transmitting the session token in another way (almost certainly HTTP Authorization: Bearer <value> tokens, commonly called "bearer tokens"). Since those have to be manually set by the caller, they are immune to CSRF (if the attacker knows the session token, they don't need to use the victim's browser/client at all).
