CSRF — Cross-Site Request Forgery

• CSRF = Cross-Site Request Forgery.

It means: an attacker tricks a logged-in user’s browser into sending an unwanted request to a trusted site.

How it works (simple steps)

1. Victim is logged into bank.com (cookie session is active).
2. Victim visits attacker site evil.com.
3. evil.com auto-submits a hidden form to bank.com/transfer.
4. Browser automatically includes victim’s bank.com cookies.
5. bank.com thinks request is legitimate and executes it.

When CSRF is possible

1. App uses cookie-based auth.
2. Sensitive action endpoint has no CSRF protection.
3. Endpoint accepts cross-site form/simple requests.

Tricky points

1. Attacker usually cannot read the response; they only need the action to execute.
2. CORS is not a full CSRF defense.
3. GET must never change state (no delete/transfer/update on GET).
4. SameSite=Lax helps, but not enough alone for all flows.
5. If you have XSS, CSRF defenses can often be bypassed.

Proper defenses (use together)

1. CSRF token on every state-changing form/API call.
2. Validate Origin (and fallback Referer) for sensitive endpoints.
3. Set cookies: Secure, HttpOnly, SameSite (Lax or Strict where possible).
4. Keep state-changing actions on POST/PUT/PATCH/DELETE, not GET.
5. Require re-auth or step-up confirmation for critical actions (password/email/payout changes).

CSRF vs SSRF (quick difference)

1. CSRF: attacker abuses victim’s browser to send requests.
2. SSRF: attacker abuses your server to send requests.