Cross-Site Request Forgery (CSRF) — Overview

What is Cross-Site Request Forgery#

Cross-Site Request Forgery (CSRF, CWE-352) is a web security vulnerability that forces authenticated users into executing state-changing actions they did not intend. Unlike XSS, the attacker does not need to access the victim's session token — the browser's automatic cookie attachment mechanism does the work. When the victim visits the attacker's page, the browser silently includes all valid session cookies for the target domain on any embedded request, and the target server processes that request as if it originated from the user.

CSRF was removed from the OWASP Top 10 in the 2021 edition on the assumption that SameSite cookies, which are now the default in Chrome 80+ and most modern browsers, would eliminate most vectors. In practice, the threat has not gone away: CVE-2024-20252 (Cisco Expressway, CVSS 9.6, February 2024) and CVE-2024-23897 (Jenkins CLI, CVSS 9.8, CISA Known Exploited Vulnerabilities catalog, January 2024) both rely on CSRF as a primary or enabling vector. A 2024 audit found that only 3.52% of websites had any SameSite attribute set, meaning the vast majority of production applications still run without this defense.

Three conditions must simultaneously be true for a CSRF attack to succeed: (1) a privileged, state-changing action exists — password change, fund transfer, account creation, admin operation; (2) the application authenticates the user exclusively via cookies, with no supplementary check like a custom header or CSRF token; and (3) all request parameters needed to execute the action are predictable or known to the attacker. When these three conditions hold, the attacker can construct a crafted page that triggers the action with one visit from the victim.

How CSRF Works#

The browser's Same-Origin Policy prevents JavaScript from reading cross-origin responses, but it does not prevent cross-origin requests from being sent. A page on evil.com can cause the browser to make a GET or form-POST request to bank.com, and the browser dutifully attaches bank.com's cookies. The server receives a syntactically valid, authenticated request with no indication that it originated on a hostile page.

The attack flow has five steps:

1. Victim authenticates to bank.com — session cookie set.
2. Victim visits evil.com (attacker-controlled page), either via phishing or an embedded ad.
3. The attacker's page contains a hidden form or image tag that targets a state-changing endpoint on bank.com.
4. The browser triggers the request automatically (on page load, or without any user interaction beyond visiting the page).
5. bank.com receives the request, validates the session cookie, finds no CSRF token check, and executes the action.

The RFC 9110 §9.2 safe method rule mandates that GET requests MUST NOT modify server state. GET-based CSRF exploits applications that violate this rule — a common anti-pattern in legacy code, admin panels with "quick-action" links, and logout endpoints.

Attack Variants#

SameSite Cookie Matrix#

Understanding when cookies are sent cross-site is fundamental to understanding the attack surface:

Real-World Examples#

CVE-2024-20252 / CVE-2024-20254 — Cisco Expressway Series (CVSS 9.6, Critical): Insufficient CSRF protections on the Cisco Expressway web API allowed an unauthenticated remote attacker to trick an authenticated administrator into following a crafted link. The attack triggered arbitrary configuration changes, account creation with elevated privileges, and DoS conditions — all at the admin's privilege level. CVE-2024-20254 was exploitable in the default configuration. Published February 2024, patch required, no workaround.

CVE-2024-23897 — Jenkins CLI (CVSS 9.8, CISA KEV, Critical): Jenkins' args4j CLI parser replaced @<filepath> arguments with file contents. Attackers read /var/jenkins_home/secrets/master.key unauthenticated, extracted the CSRF crumb secret, forged valid CSRF tokens, and executed privileged CLI actions without any user interaction beyond the initial exploit. Added to CISA's Known Exploited Vulnerabilities catalog August 2024 with a mandatory patch deadline of September 9, 2024.

CVE-2024-4994 — GitLab CE/EE GraphQL (CVSS 8.1, High): CSRF on the /api/graphql endpoint allowed unauthenticated attackers to execute arbitrary GraphQL mutations on behalf of authenticated victims. GraphQL accepted mutations via content types that did not trigger CORS preflight, defeating the assumed protection. HackerOne #1122408 ($3,370 bounty) documented the GET-request mutation vector on the same endpoint.

HackerOne #1497169 — GitHub Enterprise Management Console ($10,000): The highest-known CSRF bounty on HackerOne. The attack bypassed CSRF protection in GitHub Enterprise's server management console, enabling arbitrary administrative actions on enterprise infrastructure.

Detection#

Manual Testing#

1. Identify state-changing endpoints — log all POST/PUT/PATCH/DELETE requests plus any GET requests that modify data (look for delete, update, transfer, create in paths).
2. Check CSRF token presence — inspect each request for a csrf_token, authenticity_token, _token, __RequestVerificationToken, or XSRF-TOKEN field.
3. Test token omission — remove the token field entirely from the request body and resubmit. A 2xx response without an error message confirms the server accepts requests without a token.
4. Test blank and random tokens — submit with an empty token, then with a random same-length value. Any acceptance confirms no real validation.
5. Test cross-user token — use a valid token from a different authenticated session. Acceptance confirms the token is not session-bound.
6. Test Content-Type bypass — for JSON APIs, resend the request as Content-Type: text/plain and monitor whether the server still parses and executes the body.
7. Test SameSite attribute — inspect Set-Cookie headers. Note the SameSite value (or absence). Test state-changing GET endpoints directly via top-level navigation.
8. Test method override — append ?_method=POST or add X-HTTP-Method-Override: POST header to GET requests targeting POST endpoints. Frameworks like Symfony, Rails, and Laravel accept these.
9. Generate and test PoC — Burp Suite Pro: right-click request → Engagement tools → Generate CSRF PoC. Load in browser with victim session active.

Automated Detection#

Burp Suite Pro's CSRF PoC generator identifies the attack surface; OWASP ZAP rule 20012 flags missing tokens. XSRFProbe performs deep token analysis including omission, blank, random, and cross-user reuse. Automated scanners miss token-not-bound-to-session vulnerabilities (cross-user token reuse) and SameSite bypass chains requiring multi-step exploitation.

BreachVex detects CSRF through multiple complementary techniques: form-token analysis with a JSON API probe, a cross-origin POST probe with baseline comparison and segment-aware skip logic, and a differential GET probe that detects authenticated-vs-unauthenticated response divergence.

Prevention#

Synchronizer Token Pattern (Primary Defense)#

Generate a cryptographically random, session-bound token per user session. Embed it in every state-changing form. Validate it server-side on every state-changing request, rejecting requests that omit or present an invalid token.

# FastAPI — CSRF token generation and validation
import secrets
from fastapi import Request, HTTPException, Form
 
def generate_csrf_token() -> str:
    return secrets.token_urlsafe(32)  # 256-bit entropy
 
def validate_csrf_token(request: Request, csrf_token: str = Form(...)):
    session_token = request.session.get("csrf_token")
    if not session_token or not secrets.compare_digest(session_token, csrf_token):
        raise HTTPException(status_code=403, detail="CSRF token invalid or missing")

Use secrets.compare_digest (constant-time comparison) to prevent timing oracle attacks. Tokens must be unique per session, not per request — per-request tokens break multi-tab applications.

SameSite=Strict Cookies (Defense in Depth)#

Set SameSite=Strict on session cookies to block all cross-site requests, including top-level navigation. Use the __Host- cookie prefix to prevent subdomain injection attacks.

Set-Cookie: __Host-SID=<token>; Path=/; Secure; HttpOnly; SameSite=Strict

__Host- requires Secure, Path=/, and no Domain attribute — preventing subdomains from injecting a matching cookie that could defeat double-submit patterns.

Fetch Metadata Headers (Modern Defense)#

Implement a Resource Isolation Policy using Sec-Fetch-Site headers, which modern browsers attach to all requests (98%+ global coverage as of 2025):

# FastAPI resource isolation policy
SAFE_METHODS = {"GET", "HEAD", "OPTIONS"}
SAFE_SITES = {"same-origin", "same-site", "none"}
 
def resource_isolation_policy(request: Request):
    site = request.headers.get("Sec-Fetch-Site", "")
    mode = request.headers.get("Sec-Fetch-Mode", "")
    dest = request.headers.get("Sec-Fetch-Dest", "")
 
    if request.method in SAFE_METHODS or site in SAFE_SITES:
        return
    if mode == "navigate" and dest not in ("object", "embed"):
        return  # Allow top-level browser navigation
 
    raise HTTPException(status_code=403, detail="Cross-site request rejected")

BREACH and Token Compression Oracles#

CSRF tokens can be leaked via BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) when the server compresses responses containing both the token and attacker-controlled input in the same body. The Huffman compression oracle reveals the token character-by-character through ciphertext length measurements. Mitigation: use per-request token masking (XOR nonce, as implemented by the csrf-csrf library), or disable HTTP compression on secret-carrying responses.

Resources#

• OWASP CSRF Prevention Cheat Sheet
• PortSwigger: What is CSRF?
• CWE-352: Cross-Site Request Forgery
• RFC 9700 — OAuth 2.0 Security Best Current Practice

Related Topics#

• XSS — Cross-Site Scripting: XSS can steal CSRF tokens via XMLHttpRequest; login CSRF chains with stored XSS for account takeover.
• Session Fixation: Login CSRF and session fixation share the pre-authentication exploit surface.
• SSRF: CSRF and SSRF both abuse trusted channels — CSRF targets the user agent, SSRF targets the server's outbound stack.
• Open Redirect: Open redirects on the target domain enable SameSite=Strict bypass by converting cross-site requests into same-site navigation.