Right, this seems like a very bad idea and now everyone has to do CSRF because of it?

CORS doesn't prevent evil.com from sending a reqeust to bank.com, it only prevents reading the response, no?

So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com?

Yep, that pretty much sums it up.

CORS doesn't have to enter into it though: evil.com just has no way to read the CSRF token from bank.com, it's a one-time password that changes with every form (one hopes) and it's embedded in places that it can't access. It can send an arbitrary POST request, but no script originating from evil.com (or anywhere that is not bank.com) can get at the token it would need for that post to get past the CSRF prevention layer.

> So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com?

It can't read the response from bank.com so it can't read the CSRF token. The token is basically proving the caller is allowed to read bank.com with the user's credentials. Which is only possible if the caller lives on bank.com or a origin that bank.com has allowed via CORS.

If there's a way for evil.com to obtain a CSRF token that's valid for an arbitrary user, it's a vulnerability, just like if evil.com could obtain the user's session token, JWT, etc.

> CORS

CORS does the exact opposite to what you think.

Those types of cross-site requests are forbidden by default by the Same-Origin Policy (SOP) and CORS is designed so you can allow those requests where they would otherwise be forbidden.

CORS is not a security barrier. Adding CORS removes a security barrier.

> CORS

Incorrect. It's SOP that prevents an evil.com script from going to bank.com

It's CORS that allows evil.com. CORS is an insecurity feature that relaxes the SOP.