This site is best experienced on a laptop or desktop.
The standard CSRF double-submit cookie pattern: generate a random token, set it as a non-HttpOnly cookie and require the same value in a request header or form field. A cross-origin attacker cannot read the cookie value (same-origin policy blocks it), so they cannot reproduce the header value. The server checks cookie value equals header value: no session lookup needed. This makes it easy to implement in stateless API servers.
The double-submit pattern works because of the same-origin policy: JavaScript on attacker.com cannot read cookies set by your-app.com. The attacker can submit a form that sends the cookie automatically (that is the CSRF attack), but they cannot read the cookie value to also set the matching header.
SameSite=Strict or SameSite=Lax on the session cookie is a simpler defence that prevents the cookie being sent cross-origin at all. Most modern frameworks set SameSite=Lax by default. Double-submit is the fallback for APIs consumed by native apps or embedded in iframes across origins.
OWASP: CSRF Prevention Cheat Sheet
Covers SameSite cookies, synchroniser tokens, double-submit and the origin header check.
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html