Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser into making unauthorized requests to a web application. The browser automatically sends cookies with requests, so the server cannot distinguish legitimate from forged requests without extra measures.

Scenario:

1. Victim is logged into bank.com (session cookie in browser)
2. Victim visits attacker's page with: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. Browser sends the GET request with the bank.com cookie attached
4. Bank processes the transfer

POST CSRF requires a form:

The primary defense is a CSRF token: a random, secret, per-session (or per-request) value embedded in forms. The server validates the token on every state-changing request. An attacker on another domain cannot read the token (same-origin policy).

SameSite=Strict: cookie not sent with cross-site requests at all. SameSite=Lax: cookie sent with safe top-level navigations (links) but not with POST from other sites. Modern browsers default to Lax, significantly reducing CSRF risk.

An alternative to server-side token storage: set a random CSRF cookie and require it to also be submitted as a request parameter. An attacker cannot read the cookie (same-origin), so they cannot match it in the form data.

For AJAX requests, requiring a custom header (e.g., X-Requested-With: XMLHttpRequest) provides CSRF protection because browsers block cross-origin scripts from setting arbitrary headers (CORS enforces this).

CSRF tokens fail if:

• XSS exists — attacker can read the token via JavaScript
• Token is leaked in URL (Referer header)
• Token is predictable or reused
• CORS is misconfigured to allow the attacker's origin

Testing steps:

1. Identify state-changing requests (POST, PUT, DELETE)
2. Remove or modify the CSRF token and resubmit
3. Craft a cross-origin form submission and check if it succeeds
4. Verify SameSite attribute on session cookies

REST APIs using JSON are often exempt from CSRF if they:

• Require Content-Type: application/json (HTML forms can't set this)
• Use token-based auth (Authorization header, not cookies)

But APIs that accept cookies must still implement CSRF protection.

With SameSite=Lax as default in Chrome, Firefox, and Safari, many traditional CSRF attacks are blocked. However, subdomain attacks and certain navigation patterns can still bypass Lax. Combine SameSite with CSRF tokens for robust defense.

What is the primary defense against CSRF attacks in web applications?

CSRF exploits browser auto-attachment of cookies to forge authenticated requests from malicious sites. Primary defense: CSRF tokens validated server-side. Secondary: SameSite=Strict/Lax cookie attribute. APIs using token auth in headers (not cookies) are naturally CSRF-resistant. Combine defenses; XSS can bypass CSRF tokens if present.