CSRF: multiple-choice review
Multiple-choice synthesis across the CSRF unit — ambient authority, SameSite gaps, GET side effects, token patterns, Origin checks, and why CORS is not CSRF protection.
Six questions that cut across the whole unit. Each one mirrors a decision you make reviewing a real auth design — not a definition to recite, but a tradeoff to weigh when an endpoint changes state.
Confirm you can connect ambient authority, SameSite’s deliberate gaps, the token patterns, and Origin checks — the synthesis the lesson built toward, and the trap of mistaking CORS for a CSRF defense.
A reviewer claims 'our session cookie is HttpOnly and Secure, so we're safe from CSRF.' Why is that reasoning wrong?
Your session cookies are SameSite=Lax. A hidden form on evil.com auto-submits a cross-site POST /transfer. What happens, and which endpoint is actually still exposed?
Why is 'never perform a state change on a GET request' a real security rule and not just REST style preference?
A stateless JSON API uses the plain double-submit cookie pattern: a random value in a cookie that must be echoed in a header. An attacker controls a subdomain with an XSS. Why can they bypass it, and what's the fix?
A team adds a strict CORS policy (no foreign origins allowed) and concludes their state-changing endpoints are now CSRF-safe. Where does this reasoning fail?
An attacker logs the victim's browser into the ATTACKER's account (login CSRF), so the victim's later activity is recorded under the attacker's identity. Which defense addresses this, and why is the usual reasoning incomplete?
The through-line of the unit is one chain: cookies are ambient authority, so the browser sends your session on any request bound for your origin — including a forged write. SameSite=Lax cut the cross-site POST surface in 2020 but left GET side effects, SameSite=None, and the 120s Lax+POST window, so it is defense-in-depth, not the lock. A real defense layers an unguessable token (synchronizer for stateful apps, HMAC-signed double-submit for stateless APIs), an Origin/Referer check, and the rule that mutations never ride GET. Two traps recur: HttpOnly/Secure and CORS both feel like CSRF defenses but address reading, not the forged write that has already executed. Now when you hear “we have HttpOnly and a strict CORS policy, so we’re safe,” you know exactly which question to ask next: what stops the forged write from landing?
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.