evil.com can't see the auth cookies, but if evil.com (or anyone else) makes a request to bank.com, then that request will have the cookies for bank.com automatically included.

That is precisely why the same-origin policy sharply limits what kinds of requests evil.com is allowed to send to bank.com.

Though even still, the same-origin policy isn’t strict enough to prevent CSRF. For example, your browser will still send POSTs with Content Type application/x-www-form-urlencoded cross-origin, with cookies, even if it doesn’t let you read the response. That’s why we have to add complexity with anti-forgery tokens :/

It’ll be great when you can simply count on browsers having implemented strict SameSite cookies, because that’s such a simple, elegant solution. Anti-forgery tokens are a bit of a hack.

Isn't it easy to just block all `application/x-www-form-urlencoded` requests?

Most sites won’t want to do this, because HTML forms are useful! Also, that’s just one example, there are plenty of exemptions to the same origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

In practice, for now you either use anti-forgery tokens, you don’t put your auth tokens in cookies, or you use strict SameSite auth cookies AND block all traffic from browsers that don’t support them (mostly legacy browsers).