CSRF Protection

Cross-Site Request Forgery: When the Browser Becomes the Attacker's Tool

Cross-Site Request Forgery (CSRF) is an attack that tricks a logged-in browser into submitting an unwanted state-changing request to a vulnerable application. The attack exploits the browser's automatic inclusion of cookies (including session cookies) with every request to the target origin.

The Attack Mechanism

When a user logs into a web application, the server issues a session cookie. The browser automatically includes this cookie with every subsequent request to that application's origin. An attacker can abuse this behavior by crafting a request that the victim's browser will send with the session cookie attached.

Attack flow:

1. User logs into https://bank.com and receives a session cookie
2. User visits https://evil.com in another tab
3. evil.com contains a form that auto-submits to https://bank.com/transfer
4. The browser sends the request with the user's session cookie
5. The bank server processes the transfer, believing it was an intentional user action

Malicious HTML on evil.com:

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

The victim never sees anything — the form submits silently in the background.

Why CSRF Works

CSRF succeeds because the server cannot distinguish between:

• A request the user intentionally submitted (clicking a button on the bank's site)
• A request forged by an attacker (auto-submitted from evil.com)

Both requests contain the same session cookie. The server has no way to verify that the request originated from the application's own UI.

What CSRF Can and Cannot Do

CSRF can:

• Perform state-changing actions (transfer funds, change email, delete account, modify permissions)
• Act with the full privileges of the authenticated user
• Bypass same-origin policy for the request itself (the browser sends it)

CSRF cannot:

• Read the response (the attacker's page cannot read cross-origin responses due to same-origin policy)
• Steal the session cookie directly (unless combined with XSS)
• Access data that requires additional authentication factors (if MFA is enforced)

Vulnerable HTTP Methods

CSRF primarily targets state-changing methods:

• POST: Most common target — form submissions, API calls
• PUT: REST API updates
• DELETE: REST API deletions
• PATCH: Partial updates

GET requests can also be exploited (e.g., <img src="https://bank.com/transfer?to=attacker&amount=10000">), which is why state-changing actions should never use GET.

Defending Against CSRF with Tokens and Cookie Attributes

The primary defense against CSRF is the anti-CSRF token — a unique, unpredictable value that the server requires for every state-changing request. The token forces the attacker to read a value they cannot forge.

How Anti-CSRF Tokens Work

Token generation:
When the user authenticates, the server generates a cryptographically random token and associates it with the user's session:

import secrets

@app.route('/login', methods=['POST'])
def login():
    # ... validate credentials ...
    session['csrf_token'] = secrets.token_urlsafe(32)
    return redirect('/dashboard')

Token embedding:
The token is embedded in every form and AJAX request:

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="{{ session.csrf_token }}">
  <input type="text" name="to">
  <input type="text" name="amount">
  <button type="submit">Transfer</button>
</form>

Token validation:
The server validates the token on every state-changing request:

@app.route('/transfer', methods=['POST'])
def transfer():
    submitted_token = request.form.get('csrf_token')
    if not secrets.compare_digest(submitted_token, session.get('csrf_token', '')):
        return 'CSRF token mismatch', 403
    # ... process transfer ...

Why Tokens Defeat CSRF

The attacker on evil.com can submit a form to bank.com, but they cannot read the response from bank.com due to the same-origin policy. Therefore, they cannot obtain the CSRF token. Without the token, the server rejects the request.

Synchronizer Token Pattern vs. Double-Submit Cookie

Synchronizer Token Pattern (server-side):

• Token stored in server-side session
• Token embedded in forms
• Server compares submitted token with session token
• Most secure — token never leaves the server except in forms

Double-Submit Cookie:

• Token stored in a cookie AND submitted in the request body/header
• Server verifies that the cookie value matches the submitted value
• Works without server-side session storage
• Slightly less secure — if an attacker can set cookies on the target origin (via subdomain takeover), they can forge the token

SameSite Cookie Attributes

The SameSite cookie attribute provides a second layer of CSRF defense by controlling when cookies are sent with cross-site requests.

SameSite=Strict:

• Cookie is never sent with cross-site requests
• Strongest CSRF protection
• Downside: user clicking a link from email arrives without a session cookie (must log in again)

SameSite=Lax (default in modern browsers):

• Cookie is sent with top-level GET requests (e.g., clicking a link)
• Cookie is NOT sent with cross-site POST, PUT, DELETE, or iframe requests
• Balances security and usability

SameSite=None:

• Cookie is sent with all cross-site requests
• Requires Secure flag (HTTPS only)
• Effectively disables CSRF protection for that cookie

Defense-in-Depth Strategy

Use multiple layers:

1. Anti-CSRF tokens — primary defense for all state-changing operations
2. SameSite=Lax cookies — blocks cross-site POST requests from carrying credentials
3. Custom request headers — require a header like X-Requested-With: XMLHttpRequest for AJAX requests (cross-origin requests cannot set custom headers without CORS)
4. Re-authentication for sensitive actions — require password re-entry or MFA for high-risk operations (fund transfers, password changes)

Practice: Implement CSRF Protection

Add CSRF protection to this Express.js application:

const express = require('express');
const cookieParser = require('cookie-parser');
const csrf = require('csurf');

const app = express();
app.use(cookieParser());

// Add CSRF protection
const csrfProtection = csrf({ cookie: true });
app.use(csrfProtection);

// Expose token to templates
app.use((req, res, next) => {
  res.locals.csrfToken = req.csrfToken();
  next();
});

// In your template:
// <form action="/transfer" method="POST">
//   <input type="hidden" name="_csrf" value="{{csrfToken}}">
//   ...
// </form>

The csurf middleware automatically validates the token on all state-changing requests (POST, PUT, DELETE, PATCH) and rejects requests with missing or invalid tokens.