Security
CSRF: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s spine — ambient authority, SameSite’s deliberate gaps, the synchronizer and double-submit token patterns, Origin/Referer checks, and why CORS is not a CSRF defense — without looking back at the lesson.
- 01Why does CSRF work even though the attacker never reads the response and never reads the session cookie?
- 02Chrome made SameSite=Lax the default in 2020. State precisely what it blocks, and the three gaps it leaves.
- 03Contrast the synchronizer token pattern with the double-submit cookie pattern: how each works, and when you'd pick which.
- 04What do Origin and Referer header checks add, and why are they a defense-in-depth layer rather than a sole defense?
- 05A teammate says 'we have a strict CORS policy, so we're CSRF-safe.' Explain precisely why CORS is not a CSRF defense.
- 06What is login CSRF, why does it bite teams, and how is it defended?
If you could reconstruct each answer from memory, you hold the unit’s spine: CSRF rides ambient authority so a forged write executes with full authentication; SameSite=Lax cut the cross-site POST surface but leaves GET side effects, SameSite=None, and the 120s Lax+POST window; the synchronizer token (stateful) and HMAC-signed double-submit (stateless) are the real defenses; Origin/Referer is a cheap defense-in-depth filter, not a sole defense; CORS gates response reading, not request execution, so it is not CSRF protection; and login CSRF needs a pre-session token because the forgery precedes the session cookie.