CSRF — Cross-Site Request Forgery

What Is CSRF?#

Cross-Site Request Forgery is an attack in which an adversary tricks an authenticated user's browser into submitting a state-changing HTTP request to a web application the victim is logged into. The attacker does not need to steal the session cookie — the browser delivers it automatically. Three conditions must all be true for the attack to succeed: (1) a privileged action exists on the target — a password change, fund transfer, admin setting; (2) the application relies exclusively on session cookies with no supplementary verification; (3) all request parameters are predictable or controllable by the attacker in advance.

CSRF is classified as CWE-352 (Cross-Site Request Forgery). It appears under OWASP A01:2021 (Broken Access Control) when it bypasses access control enforcement on state-changing endpoints. It was removed as a standalone OWASP Top 10 category in 2021 — not because it is solved, but because SameSite defaults in modern browsers reduced prevalence on standard apps. Applications without SameSite-aware session cookies or explicit tokens remain fully exploitable in 2025-2026.

CSRF is distinct from XSS: XSS injects script that reads data and can steal tokens; CSRF forges outbound requests without reading anything. CSRF is distinct from SSRF: SSRF weaponizes the server's own network position; CSRF weaponizes the victim's browser session. CSRF is distinct from Clickjacking: Clickjacking overlays a transparent UI element to hijack the victim's own click; CSRF triggers the request invisibly without any click.

Mechanism#

The attack exploits the browser's automatic cookie attachment to requests. A hidden form or resource request on the attacker's page causes the victim's browser to send a request to the target application — complete with the victim's session cookie — before the victim has any opportunity to notice.

The attack unfolds in four steps:

1. The victim authenticates to the target application and receives a session cookie.
2. While still logged in, the victim visits the attacker's page (via a phishing link, ad, or injected image).
3. The attacker's page silently submits a form or loads a resource pointing at the target application endpoint.
4. The browser attaches the session cookie to the outbound request; the server processes the action as legitimate.

A concrete POST-based CSRF payload triggering a password change:

POST /account/change-password HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123xyz
 
new_password=P%40ssw0rd_attacker&confirm_password=P%40ssw0rd_attacker

The attacker's page that generates this:

<!-- Auto-submits on page load — no user interaction required -->
<form id="csrf" action="https://target.example.com/account/change-password"
      method="POST" style="display:none;">
  <input name="new_password" value="P@ssw0rd_attacker">
  <input name="confirm_password" value="P@ssw0rd_attacker">
</form>
<script>document.getElementById("csrf").submit();</script>

Attack Variants#

GET-based CSRF targets the subset of applications that perform state changes on GET requests (violating RFC 9110 §9.2). SameSite=Lax cookies are sent on top-level GET navigations — a window.location redirect or <a href> click is sufficient. <img> tags trigger subresource GETs to which Lax cookies are not attached; the actual bypass vector is top-level navigation.

JSON CSRF uses enctype="text/plain" to construct a form body that reads as valid JSON. The browser sends Content-Type: text/plain — a CORS "simple" type that triggers no preflight — while the body payload is {"action":"deleteAccount","id":123,"x":"="}. Servers that parse raw body content without validating the Content-Type header execute the mutation. CVE-2024-4994 (GitLab GraphQL) and CVE-2025-68604 (WPGraphQL) both follow this pattern.

SameSite Cookie Matrix#

SameSite is the primary browser-enforced CSRF defense. Understanding exactly what it blocks — and what it does not — is critical for both offensive testing and defensive configuration.

Cookie prefix hardening provides an additional layer against subdomain-injection attacks:

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

Only 3.52% of websites implement any SameSite attribute (2024 audit). This means 96%+ of web applications depend entirely on CSRF tokens as their only defense.

Filter Bypass Techniques#

Method override bypass (SameSite=Lax): Frameworks including Symfony, Rails, and Laravel accept _method=POST or X-HTTP-Method-Override: POST in GET requests. An attacker sends a GET with ?_method=POST&email=attacker@evil.com — the browser attaches Lax cookies to the GET, and the framework executes it as a POST. PortSwigger Lab: "SameSite Lax bypass via method override."

Client-side redirect gadget (SameSite=Strict bypass): Client-side redirects (JavaScript window.location = url_param) execute within the target origin — the browser treats the subsequent request as same-site, not cross-site. SameSite=Strict cookies are sent. An open redirect at https://target.com/redirect?url=/account/email?email=attacker@x.com exploits this.

Sibling domain attack: Same-site is defined at the eTLD+1 level. A subdomain XSS on assets.target.com can forge requests to app.target.com that are treated as same-site — bypassing SameSite=Strict and SameSite=Lax entirely. This also defeats naive double-submit cookie patterns because the attacker can inject a matching cookie via the compromised subdomain.

Token omission bypass: If a server validates the CSRF token only when the field is present (rather than requiring its presence), removing the csrf_token / authenticity_token / _token field from the form entirely bypasses protection. CVE-2023-47640 (Grails Framework, CVSS 8.8) exposed exactly this pattern.

Null Origin via sandboxed iframes: A sandboxed iframe with allow-scripts but no allow-same-origin sends Origin: null. If the server has logic if (!origin) allow(), CSRF succeeds despite SameSite=Lax.

Real-World CVEs and Incidents#

CVE-2024-23897 — Jenkins CLI Arbitrary File Read → CSRF Crumb Forgery (CVSS 9.8, CISA KEV) Jenkins ≤ 2.441 and LTS ≤ 2.426.2. The args4j CLI parser replaces @<filepath> arguments with file contents by default. Unauthenticated attackers read /var/jenkins_home/secrets/master.key and the CSRF crumb secret, then forged valid CSRF tokens to execute privileged Jenkins CLI actions without user interaction. Attack chain: file read → extract crumb → forge CSRF token → RCE. Added to CISA KEV catalog August 2024, due date September 9, 2024. Fixed in Jenkins 2.442 / LTS 2.426.3.

CVE-2024-20252 / CVE-2024-20254 — Cisco Expressway CSRF (CVSS 9.6 Critical) Cisco Expressway-C and Expressway-E, all releases before 14.3.41 and 15.0.01. Insufficient CSRF protections in the web management API allowed an unauthenticated remote attacker to trick an administrator into following a crafted link, executing arbitrary actions at admin privilege level — including system configuration changes and creation of privileged accounts. CVE-2024-20254 exploitable in default configuration; no workaround available, patch required. Published February 2024.

CVE-2024-4994 — GitLab GraphQL CSRF (CVSS 8.1, CWE-352) GitLab CE/EE 16.1.0 through 17.1.0. The GraphQL API accepted CSRF-exploitable content types (application/x-www-form-urlencoded, multipart/form-data) without preflight requirement, allowing an unauthenticated attacker to execute arbitrary GraphQL mutations on behalf of an authenticated victim. Impact: C:H/I:H. HackerOne #1122408 ($3,370 bounty) documented the GET mutation path. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N.

CVE-2024-21690 — Atlassian Confluence CSRF + Reflected XSS (CVSS 8.2) Confluence Data Center and Server 7.19.0 through 8.9.0. Combined CSRF and reflected XSS vulnerability allowing unauthenticated attackers to execute arbitrary HTML/JavaScript and compel authenticated users to perform unintended state-changing actions. Fixed in 7.19.26+, 8.5.14+, 9.0.1+.

CVE-2024-49038 — Microsoft Copilot Studio PostMessage CSRF (CVSS 9.6) Improper origin validation in Microsoft Copilot Studio's postMessage handler allowed privilege escalation via crafted messages from a cross-origin page. An attacker controls a page in an iframe or popup, posts a message to the Copilot Studio window without specifying targetOrigin, and the receiver executes the action without validating event.origin. Published November 26, 2024.

CVE-2025-68604 — WPGraphQL CSRF (CVSS 5.4) WPGraphQL ≤ 2.5.3. A remote page causes the victim's authenticated browser to submit a request to the GraphQL endpoint, executing mutations on behalf of the victim — creating unauthorized user accounts, modifying content, escalating privileges. Fixed in WPGraphQL 2.5.4. Published May 2026.

CVE-2022-24734 — MyBB Forum CSRF → RCE (CVSS 8.8) MyBB < 1.8.30. CSRF on the admin panel file upload action combined with SameSite=None on the admin session cookie and absent CSRF token validation. Impact: remote code execution via attacker-controlled file write.

HackerOne #1497169 — GitHub Enterprise Management Console CSRF ($10,000) CSRF protection bypass in GitHub Enterprise's server management console enabling arbitrary actions on enterprise infrastructure at admin privilege level. Highest known CSRF bounty on HackerOne.

HackerOne #834366 — HackerOne.com Login CSRF ($500) The authenticity_token on HackerOne's own login page was not properly verified server-side, allowing login via CSRF without a valid token — demonstrating that even security-focused platforms missed pre-authentication CSRF protection.

HackerOne #2326194 — Argo CD CSRF → Kubernetes Cluster Compromise ($4,660) Insufficient request validation in Argo CD's GitOps management interface allowed CSRF to affect the entire Kubernetes cluster configuration — full cluster compromise via a single CSRF exploit.

Detection#

Manual Testing#

1. Identify state-changing endpoints — all POST/PUT/PATCH/DELETE requests plus any GET endpoints that modify data (including logout, delete, update with query params).
2. Examine cookies — check SameSite attribute, look for __Host- or __Secure- prefixes. Absence of SameSite on Chrome 80+ = implicit Lax (2-min window still applies for new cookies).
3. Generate PoC in Burp Suite — right-click any state-changing request → Engagement tools → Generate CSRF PoC. Test in a browser where the target domain session exists.
4. Test CSRF token bypass variants:
   • Remove the token field entirely from the request — does the server reject it?
   • Submit a blank token (csrf_token=) — accepted or rejected?
   • Submit a random token of the same length — rejected?
   • Submit another user's valid token — rejected? (token not session-bound if accepted)
5. Test Content-Type bypass — change application/json to text/plain on JSON API endpoints. Observe if the server parses the body regardless of Content-Type.
6. Test GraphQL CSRF — attempt state-changing mutations via GET requests; attempt mutations with application/x-www-form-urlencoded Content-Type.
7. Test OAuth flows — check for state parameter; test with absent, blank, and static state values.
8. Test WebSocket handshakes — intercept upgrade request, modify the Origin header to a cross-origin value, verify server rejects it.

Automated Detection#

Burp Suite Pro includes a CSRF PoC generator and active scanner rule. OWASP ZAP active scan rule 20012 (Anti-CSRF Tokens Scanner) checks for missing tokens on POST endpoints. XSRFProbe CLI performs deep CSRF token analysis including omission, blank, random, and cross-user reuse testing. Semgrep rules python.django.security.audit.django-no-csrf-token and equivalent framework-specific rules catch missing @csrf_exempt decorators and missing token middleware in static analysis.

BreachVex detects CSRF via a segment-aware skip matcher that prevents false positives on read-only validation endpoints (/check, /validate, /preview) while running differential cross-origin probes on all state-changing paths. The scanner implements bearer/API-key immunity gating — endpoints using header-based auth are correctly identified as immune. The SameSite=Lax GET probe uses a cookie-jar clearing differential: GET with auth vs. GET without cookies — confirmed HIGH when the authenticated request succeeds while the cookieless request is rejected with 401/403.

Prevention#

Synchronizer Token Pattern (Primary Defense)#

The server generates a cryptographically random, session-bound token (minimum 128 bits via CSPRNG) and embeds it in every state-changing form. The server validates the token on submission — the Same-Origin Policy prevents the attacker from reading the token cross-origin.

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

Framework-specific implementations:

// Express.js — csrf-csrf (modern replacement for deprecated csurf)
import { doubleCsrf } from "csrf-csrf";
 
const { generateToken, doubleCsrfProtection } = doubleCsrf({
  getSecret: () => process.env.CSRF_SECRET,
  cookieName: "__Host-psifi.x-csrf-token",
  cookieOptions: { sameSite: "strict", secure: true, httpOnly: true },
});
 
app.get("/form", (req, res) => {
  res.render("form", { csrfToken: generateToken(req, res) });
});
 
// Apply middleware — rejects requests without valid token
app.post("/account/email", doubleCsrfProtection, requireAuth, async (req, res) => {
  await db.updateEmail(req.user.id, req.body.email);
  res.json({ success: true });
});

HMAC Double-Submit Cookie (Stateless Architecture)#

For stateless microservices and SPAs where storing tokens in server-side session is impractical, sign the token with HMAC-SHA256 bound to the session identifier and a server secret. The naive double-submit (random value in cookie + parameter, no HMAC) is vulnerable to cookie injection from compromised subdomains.

import hmac, hashlib, secrets, base64
 
def make_csrf_token(session_id: str, server_secret: bytes) -> str:
    nonce = secrets.token_bytes(16)
    sig = hmac.new(server_secret,
                   msg=(session_id.encode() + nonce),
                   digestmod=hashlib.sha256).digest()
    return base64.urlsafe_b64encode(sig + nonce).decode()
 
def verify_csrf_token(token: str, session_id: str, server_secret: bytes) -> bool:
    raw = base64.urlsafe_b64decode(token.encode())
    sig, nonce = raw[:32], raw[32:]
    expected = hmac.new(server_secret,
                        msg=(session_id.encode() + nonce),
                        digestmod=hashlib.sha256).digest()
    return hmac.compare_digest(sig, expected)

Set the cookie with __Host- prefix: Set-Cookie: __Host-csrf=<token>; Secure; Path=/; SameSite=Strict

The __Host- prefix prevents subdomain-injected cookies from overriding the legitimate CSRF cookie — blocking the sibling-domain double-submit bypass.

SameSite=Strict + Cookie Prefix#

Always set an explicit SameSite attribute. Never omit it — omission triggers the Chrome 120-second Lax+POST grace window.

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

SameSite=Strict is the correct default for admin panels, banking, and healthcare applications. It may break OAuth/SSO login flows where the authorization server redirect arrives cross-site — if so, use SameSite=Lax with an explicit CSRF token as a second layer.

Custom Request Headers (AJAX / SPA)#

Any custom header — X-Requested-With: XMLHttpRequest, X-CSRF-Token: <value> — forces a CORS preflight for cross-origin requests. Browsers cannot attach custom headers to simple cross-origin requests. Server-side: validate the custom header is present on all state-changing AJAX calls.

# FastAPI Fetch Metadata resource isolation policy
from fastapi import Request, HTTPException
 
SAFE_METHODS = {"GET", "HEAD", "OPTIONS"}
ALLOWED_SITES = {"same-origin", "same-site", "none"}
 
async 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 ALLOWED_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")

Why "GET Requests Are Safe" Is False#

BREACH Attack vs CSRF Tokens#

The BREACH attack (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) applies CRIME-like compression oracle techniques to HTTPS responses. When a server compresses HTTP responses with gzip or Brotli and a secret value (such as a CSRF token) is reflected alongside attacker-controlled input in the same response body, an attacker can iteratively determine the token's value by measuring ciphertext length changes — exploiting Huffman encoding's property that matching byte sequences compress more efficiently. Each guess that shares bytes with the secret produces a slightly shorter ciphertext, leaking the token one character at a time via ~3,000–4,000 adaptive requests.

The mitigations are independent and complementary: (1) per-request token masking — XOR the session CSRF token with a random nonce on each response and transmit masked_token = token XOR nonce plus nonce; the server recovers token = masked_token XOR nonce — this makes every reflected value unique, destroying the oracle; (2) use the csrf-csrf library (Node.js) which implements this masking pattern by default; (3) disable HTTP compression (Content-Encoding: identity) on any response that reflects a secret alongside user-controlled input; (4) combine with Content-Security-Policy to prevent BREACH-assisted cross-origin reads via sub-resource injection.

Origin / Referer Header Validation#

Secondary defense for environments where token management is not possible. Validate Origin (preferred) or Referer (fallback) on all state-changing requests. Use exact matching only — a startsWith check allows https://target.com.evil.com to pass.

def validate_origin(request: Request, expected_origin: str) -> None:
    origin = request.headers.get("Origin") or ""
    referer = request.headers.get("Referer") or ""
    source = origin or referer
    # Exact match, then slash — prevents target.com.evil.com bypass
    if not (source == expected_origin or source.startswith(expected_origin + "/")):
        raise HTTPException(status_code=403, detail="Invalid origin")
    # Explicitly reject null origin (sandboxed iframes)
    if origin == "null":
        raise HTTPException(status_code=403, detail="Null origin rejected")

Frequently Asked Questions#

What is a CSRF attack? Cross-Site Request Forgery tricks an authenticated user's browser into sending a state-changing request to a trusted application without the user's knowledge. The browser automatically attaches session cookies to every request — the attacker's page exploits this to forge privileged actions. Classified as CWE-352.

What is the difference between CSRF and XSS? XSS injects script that executes in the victim's browser origin and can read data, steal cookies, and call APIs. CSRF forges outbound requests without reading responses — it executes actions. XSS can bypass CSRF tokens by reading them from the DOM via XMLHttpRequest.

Does SameSite=Lax prevent CSRF? Partially. It blocks cross-site POST form submissions but allows cross-site GET navigations and the Chrome 120-second Lax+POST grace window. Combine SameSite=Lax with a CSRF token.

What is the Synchronizer Token Pattern? A cryptographically random, session-bound token embedded in every state-changing form. The server validates it on submission. Attackers cannot read the token cross-origin, so forged forms fail.

Is a JSON API CSRF-immune? No. enctype="text/plain" forms create a JSON-shaped body sent as Content-Type: text/plain — a CORS simple request that triggers no preflight. Servers that parse body JSON regardless of Content-Type are fully exploitable. CVE-2024-4994 (GitLab GraphQL, CVSS 8.1) demonstrates this.

What is Login CSRF? An attack that forces the victim to authenticate as the attacker's account on a pre-authentication endpoint (no session, no token). The victim then stores data in the attacker's account context.

What is the 2-minute Lax window? Chrome's Lax+POST grace period allows cross-site POSTs if the session cookie was issued within the past 120 seconds. An attacker forces re-authentication via a logout redirect then immediately fires the CSRF payload within that window.

Can CSRF bypass 2FA? No. CSRF operates on an existing authenticated session in which 2FA has already been passed. It cannot bypass the authentication step itself.

Resources#

• Score this vulnerability with our free CVSS v4.0 calculator
• OWASP CSRF Prevention Cheat Sheet
• PortSwigger Web Security Academy — CSRF
• RFC 9700 — OAuth 2.0 Security Best Current Practice (January 2025)
• MDN — SameSite cookies