Security
CSRF: multiple-choice review
Crux 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.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix 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.
Goal
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.
Quiz
Completed
A reviewer claims 'our session cookie is HttpOnly and Secure, so we're safe from CSRF.' Why is that reasoning wrong?
Heads-up HttpOnly is alive and useful — but against XSS cookie theft, a different attack class. The reasoning is wrong because CSRF never needed to read the cookie in the first place.
Heads-up HttpOnly governs JavaScript access to the cookie value, not whether the browser attaches it to a request. The browser still auto-sends it cross-site; that is exactly the ambient authority CSRF rides.
Heads-up Secure only forces the cookie onto HTTPS connections. The forged request is made over HTTPS too, with the cookie attached for free. Transport encryption is orthogonal to CSRF.
Quiz
Completed
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?
Heads-up Lax specifically strips the cookie from cross-site POST subrequests; that is its main win. The remaining exposure is GET-based state changes on top-level navigation, not the POST.
Heads-up Lax is not Strict. It deliberately sends the cookie on top-level navigations using safe methods, so a GET that mutates state is still forgeable by getting the victim to follow a link.
Heads-up Lax leaves three gaps: GET side effects, SameSite=None cookies, and the default-Lax 120s Lax+POST window. It is defense-in-depth, never the only lock.
Quiz
Completed
Why is 'never perform a state change on a GET request' a real security rule and not just REST style preference?
Heads-up Performance is irrelevant here. The security point is that Lax still attaches cookies to top-level GET navigations, so a mutating GET is directly CSRF-able.
Heads-up Caching is a correctness concern, not the security reason. The real issue is that a GET side effect is reachable via a forged top-level navigation that carries the Lax cookie.
Heads-up In practice GET endpoints are routinely exempted from token checks and are triggerable by plain links and image tags. Keeping mutations off GET closes the cheapest CSRF vector before any token logic runs.
Quiz
Completed
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?
Heads-up Double-submit is genuinely stateless — that's its appeal. The weakness is that it assumes the attacker can't write your cookies; a subdomain XSS or cookie injection breaks that assumption.
Heads-up The same-origin policy stops cross-site reads of your headers and cookie value. The break here is cookie writability via a subdomain, not readability.
Heads-up The HMAC-signed double-submit binds the token to the session so a planted value won't validate, keeping the pattern stateless. The synchronizer token (stateful) is stronger but not the only option.
Quiz
Completed
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?
Heads-up CORS does not block requests from being sent or executed; it controls the browser's exposure of the response to script. The forged write still lands. CORS is not a CSRF defense.
Heads-up CORS applies across methods, but in all cases it gates response readability, not request execution. The mutation happens before CORS matters.
Heads-up Preflight only fires for non-simple requests. Simple requests and top-level form posts skip it entirely and execute their side effect — which is precisely why CORS can't be the CSRF defense.
Quiz
Completed
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?
Heads-up It is not harmless: the victim then enters data, payment details, or search history that lands in the attacker's account where the attacker can later read it. Login CSRF is a real, named threat.
Heads-up SameSite governs the session cookie, but login CSRF forges the login POST before any session cookie exists. You need a pre-session token on the login form, not just SameSite on the post-login cookie.
Heads-up Encryption protects confidentiality in transit; it does nothing about a forged top-level login submission. The defense is a CSRF token covering the unauthenticated login flow.
Recap
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.