How does CSRF work when the attacker cannot read cookies?
What interviewers are testing
CSRF separates people who understand the browser credential model from people who repeat "use a CSRF token". Interviewers probe why the attacker never needs to read the cookie, why the same-origin policy does not help, and whether you know that POST-only APIs and default-Lax cookies change the risk surface without eliminating it. The best answers connect browser policy, server validation, and API design into one story.
Mental model
The browser chooses which cookies to attach by looking at the request destination, not at the page that initiated it. So evil.com can make the victim browser send an authenticated request to bank.com while never reading the cookie or the response. Defenses either stop the browser from attaching credentials (SameSite) or make the server verify intent independently of ambient cookies (CSRF tokens, Origin checks) — and state-changing GET endpoints break both stories.
Step-by-step solution
Step 1 of 5
Cookies travel by destination
Cookies are not attached by the page that initiates a request; they are attached by the browser according to the request destination origin. That single fact is the foundation of CSRF. When the victim is logged into bank.com, the session cookie lives in the browser cookie store. Any page, including evil.com, can cause the browser to submit a form, load an image, or fire a no-cors fetch whose destination is bank.com, and the browser will attach the bank cookie because the destination matches. The attacker never sees that cookie and does not need to. The animation follows the request: the evil site triggers a transfer POST, the browser reaches into the cookie store, attaches the session cookie, and the bank server processes the request as the logged-in user. The response is unreadable cross-origin, but the money already moved.
Animation — Cookies travel by destination
bank.com session
The victim logs into bank.com and receives a session cookie.
Edge cases & traps
- Assuming POST-only is safe: HTML forms POST cross-site as simple requests without preflight — require a CSRF token or SameSite instead of trusting the method.
- Forgetting GET side effects: links, images, and prefetchers trigger top-level or subresource GETs that still carry Lax cookies — never change state on GET.
- Using SameSite=None without Secure: browsers reject insecure None cookies, and None sends them on every cross-site request — pair None with Secure and a CSRF token.
- Trusting the Origin header when it is absent: some clients omit it — fall back to Referer, validate against an allowlist, and fail closed for state-changing requests.
- Storing SPA tokens in localStorage to dodge CSRF: the vulnerability disappears but XSS theft takes over — pick the threat you can mitigate and layer defenses.