In more detail
Because browsers attach cookies automatically, a malicious page can make your browser submit a form to your bank. Defences are anti-CSRF tokens that an attacker cannot guess, SameSite cookies and checking the Origin header. It differs from Cross-site scripting (XSS): CSRF abuses the site's trust in your browser, XSS abuses your browser's trust in the site. The attacker cannot read the response; the damage comes from the side effect, such as a transfer, a changed email address or a new admin user.
Why it matters
Any state-changing request that relies only on a session Cookie is exposed. Modern browsers treat cookies without a SameSite attribute as Lax by default, which blocks the classic cross-site form POST, but not every browser does, SameSite=None cookies stay exposed, and same-site subdomains can still attack each other. Tokens remain the main defence; never change state with GET.
Example
An attacker's page that submits a hidden transfer form as soon as it loads:
<form action="https://bank.example/transfer" method="POST">
<input type="hidden" name="to" value="attacker">
<input type="hidden" name="amount" value="1000">
</form>
<script>document.forms[0].submit()</script>
The fix on the bank's side: a per-session token in a hidden field that the server checks, plus a cookie such as Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax.
Common confusion
CORS does not stop CSRF. CORS controls whether a page may read a cross-origin response; a plain form POST is sent without any CORS check.