The protection provided by this technique can be thwarted if the target website disables its same-origin policy using one of the following techniques: Permissive Access-Control-Allow-Origin Cross-origin resource sharing header (with asterisk argument)

The article https://en.wikipedia.org/wiki/Same-origin_policy#Security_Applications also says:

The user visiting the malicious site would expect that the site he or she is visiting has no access to the banking session cookie. While it is true that the JavaScript has no direct access to the banking session cookie, it could still send and receive requests to the banking site with the banking site's session cookie. Because the script can essentially do the same as the user would do, even CSRF protections by the banking site would not be effective.

Is this still true if doing client side rendering and all server requests are ajax get/post calls with a required token in cookies plus custom header? I think the token can be stolen, if the server is rendering the CSRF token into forms, by sending a GET with the user's session cookie, and parsing the response HTML, but as far as I know a malicious site' JS can't read another site's cookies even with Access-Control-Allow-Origin set to the malicious site and Access-Control-Allow-Credentials set to true.

I know setting allow-origin to the request origin is stupid, but am just wondering if I'm missing something that makes it easy to exploit the above CSRF prevention.