Classic GET-based CSRF

What is Classic GET-based CSRF#

Classic GET-based CSRF (CWE-352) exploits web endpoints that perform state-changing operations in response to GET requests. RFC 9110 §9.2 defines GET as a "safe" method that MUST NOT modify server state. When developers implement destructive or state-changing functionality on GET endpoints — legacy PHP admin panels, quick-action buttons, logout links — they expose every authenticated visitor to one-click attack via any page they visit.

The attack requires no user interaction beyond visiting the attacker's page. An <img> tag with a src pointing to the target endpoint causes the browser to issue an authenticated GET request immediately upon page load. The victim never sees anything visual — a zero-pixel image is invisible. This makes GET-based CSRF the simplest, most reliable CSRF variant: no JavaScript required, no form submission needed, and no SameSite=Lax protection for top-level GET navigation attacks.

The modern distinction matters: <img> triggers a subresource GET (blocked by SameSite=Lax), while <a href> or window.location triggers a top-level navigation GET (Lax cookies ARE sent). Both vectors work against different cookie configurations. Against SameSite=None or absent cookies, both work. Against SameSite=Lax, only the navigation variants succeed.

Mechanism#

The attack chain uses the browser's automatic cookie attachment on any outbound request to a domain for which the victim holds a valid session.

Attack steps:

1. Victim is authenticated to target.com (session cookie present in browser).
2. Victim visits evil.com — either via phishing, malvertising, or a compromised page.
3. The attacker's page contains an <img> tag, script redirect, or clickable link targeting a state-changing GET endpoint.
4. Browser issues the GET request with the victim's session cookie attached.
5. Server validates the session, finds no CSRF token requirement on GET, and executes the action.

Attack payloads — three delivery vectors:

<!-- Vector 1: Image tag — zero-click, fires on page load -->
<!-- Works against SameSite=None/Absent; BLOCKED by SameSite=Lax (subresource) -->
<img src="https://bank.com/transfer?to=attacker&amount=5000" width="1" height="1">
 
<!-- Vector 2: Top-level navigation redirect — bypasses SameSite=Lax -->
<!-- Lax cookies ARE sent on top-level GET navigations -->
<script>window.location = 'https://bank.com/transfer?to=attacker&amount=5000';</script>
 
<!-- Vector 3: Clickable link — social engineering, bypasses SameSite=Lax -->
<a href="https://target.com/admin/users/42/delete">Click here to claim your prize</a>

The critical SameSite=Lax distinction:

Browser sends SameSite=Lax cookie on:   top-level GET navigation (window.location, <a href>, address bar)
Browser BLOCKS SameSite=Lax cookie on:  <img src>, <script src>, <iframe src>, fetch(), XMLHttpRequest

Attackers targeting Lax-protected apps use window.location or redirect chains rather than <img> tags. The practical difference is that the navigation vector requires a page visit trigger (easily achieved with an auto-redirect) rather than page load.

Attack Variants#

The method override vector deserves particular attention. Symfony, Rails (_method), Laravel, and some Express middleware accept a _method=POST query parameter on GET requests. An attacker sends a GET with ?_method=POST — the browser sends SameSite=Lax cookies because it's a GET — and the framework processes it as a POST, executing the state change.

GET /account/email?_method=POST&email=attacker@evil.com HTTP/1.1
Host: target.com
Cookie: session=victim_session_token

Real-World Examples#

CVE-2024-23902 — Jenkins GitLab Branch Source Plugin: Form validation on this plugin endpoint did not require POST — the endpoint accepted GET requests for state-changing operations including connecting to attacker-specified URLs. CVSS Medium, vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N. Fixed in version 688.v5fa_356ee8520. Published January 24, 2024.

CVE-2024-20254 — Cisco Expressway CSRF (CVSS 9.6): The Cisco Expressway API management interface contained insufficient CSRF protections on endpoints controlling device configuration. An unauthenticated remote attacker could trick an authenticated administrator into visiting a crafted link, triggering arbitrary configuration changes at admin privilege level. CVE-2024-20254 was exploitable in the default Expressway configuration, with no authentication precondition for the attacker.

CVE-2023-47640 — Grails Framework (CVSS 8.8): Grails' built-in CSRF protection was bypassed by completely omitting the token field from GET requests to endpoints that the framework should have protected. The token omission pattern — accepted when missing — is the foundation of both GET and POST CSRF attacks. Affected Grails < 5.3.4, requiring a framework upgrade.

HackerOne #2326194 — Argo CD / Kubernetes ($4,660): Insufficient request validation in Argo CD's GitOps management interface allowed CSRF to affect the entire Kubernetes cluster configuration — arbitrary cluster reconfiguration via CSRF on a management endpoint.

Detection#

Manual Testing#

1. Identify state-changing operations by reviewing all application functionality: user management, financial transfers, content publishing, settings changes, and administrative operations.
2. For each state-changing operation, determine whether it can be triggered via GET. Use Burp Suite to replay POST requests as GET — a 200 or redirect (not 405 Method Not Allowed) confirms GET acceptance.
3. Check path keywords: delete, remove, destroy, transfer, update, promote, ban, revoke, approve, confirm, reset. GET endpoints containing these words are high-priority targets.
4. Verify authentication gate: replay the GET without any session cookie. A 401 or 403 response confirms the endpoint is auth-gated — this is required for CSRF impact.
5. Inspect Set-Cookie headers for SameSite attribute. Absent or SameSite=None means <img> attacks work. SameSite=Lax means navigation vectors work. SameSite=Strict blocks most GET vectors (test open redirect chain for bypass).
6. Generate a PoC using Burp Suite's CSRF PoC generator and test in a browser with a victim session.

Automated Detection#

BreachVex detects GET-based CSRF using a two-probe differential: authenticated GET (records status) vs. unauthenticated GET (cookie jar cleared). Endpoints returning HTTP 2xx with auth and HTTP 401/403 without auth are confirmed auth-gated. The probe skips irreversible destructive endpoints in safe mode (paths containing delete, destroy, kill) to prevent side effects during scanning.

Prevention#

Enforce POST for State-Changing Operations (Primary Fix)#

Never perform state changes on GET requests. Follow RFC 9110 §9.2: GET, HEAD, and OPTIONS must be idempotent and side-effect-free.

# FastAPI — enforce POST for all state-changing operations
from fastapi import APIRouter, Request, HTTPException, Depends
 
router = APIRouter()
 
# VULNERABLE: state change on GET
@router.get("/admin/users/{user_id}/delete")
async def delete_user_bad(user_id: int):
    await db.delete_user(user_id)  # DO NOT DO THIS
    return {"ok": True}
 
# SAFE: state change on POST with CSRF token validation
@router.post("/admin/users/{user_id}/delete")
async def delete_user_safe(
    user_id: int,
    request: Request,
    csrf_token: str = Form(...),
    current_user = Depends(require_admin)
):
    validate_csrf_token(request, csrf_token)
    await db.delete_user(user_id)
    return {"ok": True}

CSRF Token on All State-Changing Forms#

<!-- Every state-changing form must include the CSRF token -->
<form action="/admin/users/42/delete" method="POST">
  <input type="hidden" name="csrf_token" value="{{ csrf_token() }}">
  <button type="submit">Delete User</button>
</form>

// For AJAX requests: read token from meta tag and include in headers
const csrfToken = document.querySelector('meta[name="csrf-token"]').content;
fetch('/admin/users/42/delete', {
  method: 'POST',
  headers: { 'X-CSRF-Token': csrfToken, 'Content-Type': 'application/json' },
  credentials: 'same-origin',
  body: JSON.stringify({ confirm: true }),
});

Cookie Configuration#

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

Use SameSite=Strict rather than Lax to block all cross-site requests including top-level navigation. The __Host- prefix prevents subdomains from injecting override cookies.

Resources#

• CSRF — Pillar Overview
• PortSwigger: CSRF Bypass Labs
• RFC 9110 §9.2: Safe Methods
• OWASP CSRF Prevention Cheat Sheet