What conditions make CSRF (Cross-Site Request Forgery) possible?

CSRF works when the browser auto-attaches the victim's session cookie to a cross-site request and the server has no extra check (CSRF token, SameSite, Origin) — so an attacker's page can fire an authenticated action on the victim's behalf.

* CSRF — the victim's browser auto-attaches the session cookie to the attacker-triggered request, so the server can't tell it from a legitimate action. *

CSRF tricks a victim's browser into making authenticated requests to a site where they're already logged in.

Required conditions:

1. Session/auth sent automatically: Browser includes cookies with every request to that domain
2. No SameSite=Strict cookie: Cookie is sent even from cross-origin requests
3. No CSRF token validation: Server doesn't verify request originated from its own forms
4. Sensitive action via simple request: Action possible with GET or form POST

How attack works:

1. Victim is logged into bank.com
2. Victim visits attacker's page
3. Page contains: <img src="https://bank.com/transfer?to=attacker&amount=1000">
4. Browser sends request WITH victim's bank.com cookies
5. Bank processes transfer as if victim initiated it

Prevention:

• SameSite=Strict or SameSite=Lax cookies
• Require CSRF tokens in forms
• Verify Origin/Referer headers
• Require re-authentication for sensitive actions

Go deeper:

• PortSwigger — Cross-site request forgery (CSRF) — maps the required conditions to attack/defense (tokens, SameSite, Origin) with labs.
• Cross-site request forgery (Wikipedia) — the trust-in-the-browser model and the token / SameSite defenses.