Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that tricks a victim's browser into sending an unwanted request to a web application where the victim is authenticated. Because the browser automatically includes cookies with every request to the site, the application cannot distinguish between a legitimate request and a forged one.

---

How CSRF Works

CSRF exploits the trust a web application places in the user's browser. If a user is logged into their bank and visits a malicious page, that page can trigger a request to the bank — and the browser will include the user's session cookie automatically.

Attack Flow

1. Victim logs into https://bank.com (session cookie set)
2. Victim visits https://evil.com (while still logged into bank)
3. evil.com contains: <img src="https://bank.com/transfer?to=attacker&amount=10000">
4. Victim's browser sends the request to bank.com WITH the session cookie
5. bank.com processes the transfer because the session is valid

---

CSRF Attack Examples

GET-Based CSRF

The simplest form — an image tag or link triggers the request:

<!-- Hidden on the attacker's page -->
<img src="https://bank.com/transfer?to=attacker&amount=5000" width="0" height="0">

Note: State-changing operations should never use GET requests. This is why the HTTP specification states that GET should be used only for safe, idempotent operations.

POST-Based CSRF

Uses a hidden form that is automatically submitted:

<form action="https://bank.com/transfer" method="POST" id="csrf-form">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="5000">
</form>
<script>document.getElementById('csrf-form').submit();</script>

JSON-Based CSRF

Some applications accept JSON bodies. If CORS is misconfigured, an attacker can send JSON:

<form action="https://api.bank.com/transfer" method="POST" enctype="text/plain">
  <input name='{"to":"attacker","amount":5000,"ignore":"' value='"}'>
</form>
<script>document.forms[0].submit();</script>

---

Conditions Required for CSRF

For a CSRF attack to succeed, all three conditions must be met:

Condition	Description
Relevant action	There must be an action the attacker wants to trigger (money transfer, password change, etc.)
Cookie-based session	The application must use cookies for session management (cookies are sent automatically)
No unpredictable parameters	The request must not contain any values the attacker cannot guess (like a CSRF token)

---

CSRF Prevention Techniques

1. Anti-CSRF Tokens (Synchroniser Token Pattern)

The most widely used defence. The server generates a unique, unpredictable token for each session (or form) and includes it as a hidden field:

<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="a8b3c2d1e4f5a6b7c8d9e0f1a2b3c4d5">
  <input name="to" value="">
  <input name="amount" value="">
  <button type="submit">Transfer</button>
</form>

The server validates the token on every state-changing request. An attacker on a different origin cannot read the token, so they cannot include it in a forged request.

2. SameSite Cookie Attribute

The SameSite cookie attribute restricts when cookies are sent cross-origin:

Value	Behaviour
Strict	Cookie is never sent on cross-origin requests (maximum protection)
Lax	Cookie is sent on top-level navigations (GET only), not on cross-origin POST/PUT/DELETE
None	Cookie is always sent (requires Secure flag; offers no CSRF protection)