CSRF Protection Flow: Mermaid Flowchart Diagram

About Source

Cross-Site Request Forgery (CSRF) is an attack where a malicious website tricks an authenticated user's browser into sending a state-changing request to another site where the user is logged in — exploiting the browser's automatic cookie sending behavior.

The attack works because browsers automatically attach cookies to any request matching the cookie's domain, regardless of which site initiated the request. If a user is logged into bank.com and visits a malicious page, that page can silently submit a form or trigger a fetch to bank.com/transfer?amount=1000&to=attacker. The browser attaches the user's session cookie, and the bank server sees an authenticated request.

The classic defense is the synchronizer token pattern. The server generates a random, unpredictable CSRF token tied to the user's session and embeds it in every HTML form as a hidden field (or exposes it via a meta tag / cookie for AJAX use). When the form is submitted, the server validates that the submitted CSRF token matches the one it issued. A cross-origin attacker cannot read the CSRF token from the HTML (blocked by same-origin policy), so they cannot include a valid token in their forged request.

For AJAX-heavy applications, a common pattern is the double-submit cookie: the server sets a CSRF token as a readable (non-HttpOnly) cookie, and JavaScript reads it and includes it as a request header (e.g., X-CSRF-Token). The server validates that the header value matches the cookie. Cross-origin requests cannot set or read this custom header.

Modern applications can also rely on SameSite=Lax or SameSite=Strict cookies, which prevent cookies from being sent on cross-site POST requests entirely. This is now the browser default and provides strong CSRF protection without explicit tokens for most workflows. See Secure Cookie Flow for SameSite configuration details.

Frequently asked questions

CSRF (Cross-Site Request Forgery) is an attack where a malicious website causes an authenticated user's browser to send a state-changing request to a different site. Because browsers automatically attach cookies to matching requests, the target server sees what looks like a legitimate authenticated request and processes it unless a CSRF defense is in place.

The server generates a unique random token tied to the user's session and embeds it in every form as a hidden field. On submission, the server checks that the submitted token matches the session-bound token. Since the attacker cannot read the victim's HTML (blocked by same-origin policy), they cannot forge a request that includes a valid token.

`SameSite=Lax` (the modern browser default) blocks cross-site POST requests automatically, providing CSRF protection for most form-based workflows without explicit token handling. Explicit CSRF tokens remain important for applications that need to support older browsers, use cross-origin form submissions intentionally, or cannot rely on cookie-based authentication at all.

XSS injects and executes attacker-controlled scripts within the victim's own browser session on the target origin. CSRF tricks the victim's browser into sending a request to the target origin from an external page, exploiting cookie auto-attachment. XSS can steal CSRF tokens; combining both attacks is a common escalation path.

mermaid

flowchart TD
    A[User visits legitimate app\nand is authenticated] --> B[Server generates random CSRF token\ntied to user session]
    B --> C[Embed token in HTML form\nas hidden field\nOR set as readable cookie for AJAX]
    C --> D[User submits form or AJAX request\nCSRF token included in body/header]

    D --> E[Server receives request]
    E --> F[Extract CSRF token\nfrom request body or header]
    F --> G[Retrieve expected CSRF token\nfrom user session]
    G --> H{Tokens match?}
    H -- Yes --> I[Process legitimate request]
    H -- No or missing --> J[Reject: 403 Forbidden]

    subgraph CSRF Attack Attempt
        K[Attacker page triggers\ncross-origin POST to bank.com] --> L[Browser sends session cookie\nautomatically]
        L --> M[But attacker cannot read\nCSRF token from bank.com HTML\nblocked by same-origin policy]
        M --> N[Request missing valid CSRF token]
        N --> J
    end