CSRF Attacks and Defense

• It attacks the trust relationship between a browser and a service — the victim is the vector, not the target.
• Modern frameworks default many things right now, but legacy GET-mutation code and cookie-only auth still get bitten.
• The controls (SameSite, tokens, origin checks) are now cheap and standard — you need to know which stack already does what.

The bank honors it because the signature is right; nobody checks who sent the envelope.

• The victim is logged in with session cookies that the browser auto-sends on any request to the site.
• The attacker hosts a page that submits a form or loads a URL to the victimized site (transfer, logout, change password).
• Because the cookies ride along and the site trusts them, the victim's browser executes the action in the victim's name.
• Defenses attack each link: SameSite cookies bind sending scope, anti-CSRF tokens prove intent, origin checks reject cross-site requests.

• A fintech enabled SameSite=Lax globally and saw their CSRF ticket count drop to near zero overnight.
• A CMS wrapped every mutating endpoint in a double-submit token check at the framework level, not per-route.
• An admin panel rejects any state change without a custom Origin/Sec-Fetch-Site header check as a second layer.

• Send Set-Cookie with SameSite=Lax or Strict, HttpOnly, Secure, and a distinct session cookie name.
• Use framework anti-CSRF tokens on every state-changing request; validate server-side, never client-side.
• Verify Origin/Referer (and Sec-Fetch-Site) on mutating endpoints as a cheap complementary control.
• Never allow state changes via GET; route mutations to POST/PUT/DELETE and enforce it at the router.

• Fortifying login but forgetting the account-transfer and settings pages are equally state-mutating.
• Checking the Referer header but tolerating 'null'/missing values, flipping the check off for the trickiest browsers.
• Using a token that's predictable (timestamp hash) or reused across sessions.
• Assuming SameSite alone; a subdomain takeover or downgrade can still surface a Full CSRF chain.

• Reproduce by opening one of your own mutation URLs in a fresh tab — if it fires without any explicit action, it's CSRF-flagged.
• Inspect the Set-Cookie header with devtools: the SameSite attribute tells you what the browser will allow.
• When tokens fail in tests, check the cookie flags and whether the token is bound to the session ID or app-wide.

• CSRF experiments belong in your lab app; a forged request against a working service is a real change you did not make.
• Log cross-origin mutation attempts that fail your controls — they are reconnaissance evidence.
• Pair CSRF defense with strict session hardening so a token leak can't be reused for login.