Security
CSRF: build the exploit, then the defense
Reading about CSRF is not the same as watching a forged request move real money on your own machine. Build a small cookie-session app, write the attacker page that exploits it, then add the unit’s defenses one layer at a time — proving each exploit dies as you go.
Turn the unit’s mental model into a reproducible loop: stand up a vulnerable target, demonstrate a working CSRF, then layer SameSite, a token defense, and an Origin check, verifying after each layer that the forged request fails for the right reason.
Build a deliberately CSRF-vulnerable cookie-session web app and a separate attacker origin, exploit it end-to-end, then harden it with SameSite, a CSRF token, and an Origin check — proving with a real cross-origin attacker page that every documented vector fails after hardening.
- A before/after exploit log: for each vector (cross-site POST, GET side effect, login CSRF) show it succeeding pre-hardening and failing post-hardening, with the server response/status as evidence — observed, not asserted.
- A defense matrix mapping each vector to the layer that stops it (SameSite, token, GET-to-POST move, Origin check) and noting which layers are redundant defense-in-depth versus the load-bearing one.
- The token defense is shown to reject a forged request that omits or guesses the token, and to accept a legitimate same-origin request — both demonstrated, not claimed.
- A one-paragraph write-up explaining why SameSite alone was insufficient and which single layer would have been the minimum viable defense if you could keep only one.
- Demonstrate a SameSite bypass: exploit the GET state-change under SameSite=Lax via a top-level navigation, and (if your browser exposes it) the ~120s default-Lax Lax+POST window right after login.
- Break your own plain double-submit defense by simulating an attacker-controlled cookie write (e.g. a sibling subdomain), then fix it by switching to the HMAC-signed variant bound to the session and show the exploit dies.
- Add a JSON API route protected only by a custom-header + non-simple content-type preflight requirement, then show from origin B that a forged cross-site fetch can't satisfy the preflight — and explain why a top-level form post would still bypass this if the route accepted form encoding.
- Write a short threat-model note: enumerate each state-changing endpoint, its method, its SameSite reliance, and its token coverage, and flag any route where a single layer failing would reopen the hole.
This is the loop you will run when securing any cookie-session app: build the vulnerable version, prove the exploit on your own machine, then layer defenses and verify each forged request dies for the right reason. SameSite=Lax kills the cross-site POST but leaves GET side effects and the None/login-CSRF gaps; a real token defense (synchronizer for stateful, HMAC double-submit for stateless) is the load-bearing layer; moving mutations off GET and checking Origin/Referer are the defense-in-depth that catches what slips through. Doing it once against your own attacker page makes the production posture muscle memory.