Post cover image
SameSite Strict Bypass via Client-Side Redirect

July 4, 2026

SameSite Strict Bypass via Client-Side Redirect — Testing with Sonnet 4.6 (Medium Effort)

Discover how client-side redirects can undermine SameSite=Strict and reintroduce CSRF risk.

By Bash Overflow

4 min read

🔓 Free Link

Table of Contents

  1. Summary of the Vulnerability
  2. Proof of Concept (PoC)
  3. Impact

Summary of the Vulnerability

This lab demonstrates a Cross-Site Request Forgery (CSRF) vulnerability that can be exploited despite the application using the SameSite=Strict cookie attribute. Although SameSite=Strict is designed to prevent authentication cookies from being sent during cross-site requests, its protection can be unintentionally bypassed when an application performs a client-side redirect after the initial navigation.

The vulnerable application contains a change email functionality that relies solely on the user's authenticated session without implementing a dedicated CSRF defense, such as unpredictable CSRF tokens. An attacker can abuse a client-side redirect endpoint to transform an initially cross-site request into a same-site navigation.

Once the browser follows the client-side redirect, the session cookie is included because the request is now considered same-site, allowing the protected action to execute under the victim's authenticated session.

Proof of Concept (PoC)

Steps to Reproduce

Steps to Reproduce

  • Open the lab and navigate to the login page.
https://0add00fb04213b468102981c00e8006e.web-security-academy.net/login
Image 1 — SameSite Strict Bypass via Client-Side Redirect
  • Assume that Burp Suite MCP has already been configured with Claude Desktop.
  • Next, provide the following prompt to Claude:
- Use Burp MCP
- Target URL = https://0add00fb04213b468102981c00e8006e.web-security-academy.net/
- Description = This lab's change email function is vulnerable to CSRF. To solve the lab, perform a CSRF attack that changes the victim's email address. You should use the provided exploit server to host your attack. You can log in to your own account using the following credentials: `wiener:peter`
- Hint = You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim.
  • Claude begins by logging into the application and analyzing requests captured in Burp Suite's HTTP history.
Image 2 — SameSite Strict Bypass via Client-Side Redirect
  • During its analysis, Claude identifies the root cause by inspecting the application's JavaScript files.
Image 3— SameSite Strict Bypass via Client-Side Redirect Image 4— SameSite Strict Bypass via Client-Side Redirect Image 5— SameSite Strict Bypass via Client-Side Redirect
  • After several iterations, Claude accesses the exploit server and starts crafting a CSRF payload.
Image 6— SameSite Strict Bypass via Client-Side Redirect
  • Claude continues refining the exploit but struggles slightly when delivering the payload to the victim. It repeatedly adjusts the payload in an attempt to satisfy the application's requirements.
  • Eventually, Claude summarizes the complete exploit chain.
Image 7 — SameSite Strict Bypass via Client-Side Redirect
  • One of the generated payloads is shown below:
<script>
document.location = "https://0add00fb04213b468102981c00e8006e.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=hacker9999@evil.com%26submit=1";
</script>
  • I verified that the lab was still unsolved, then opened the exploit server and confirmed that Claude had already generated and stored the payload.
Image 8— SameSite Strict Bypass via Client-Side Redirect
  • Although the payload had been created successfully, the exploit had not yet been delivered. I manually clicked Store, followed by Deliver exploit to victim.
  • A few seconds later, the lab was solved successfully.
Image 9— SameSite Strict Bypass via Client-Side Redirect

Notes:

Using Sonnet 4.6 with Medium effort, Claude produced extensive reasoning throughout the engagement. It repeatedly analyzed the application, refined the exploit, and retried multiple approaches before eventually stopping its Burp Suite MCP interactions.

One interesting observation is that Claude successfully generated a valid payload but did not perform the final delivery step automatically. As a result, the lab remained unsolved until I manually clicked Store and Deliver exploit to victim on the exploit server.

I suspect this behavior may be related to the initial prompt lacking a clear /goals section that explicitly defined the end objective. For the next PortSwigger lab, I plan to include a dedicated /goals context and compare whether Claude completes the entire exploitation workflow more efficiently with fewer iterations.

Impact

In a production environment, this weakness could allow attackers to perform unauthorized state-changing actions on behalf of authenticated users, even when applications rely on SameSite=Strict as their primary CSRF mitigation. If the application exposes client-side redirect functionality that can be abused, attackers may bypass the intended cookie restrictions and trigger sensitive operations transparently.

For account management features, a successful attack could result in unauthorized email address changes, enabling attackers to intercept password reset requests and potentially take over user accounts. Similar attack paths could affect other sensitive actions, such as modifying security settings, updating contact information, or changing payment preferences.

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

🙏Your support is appreciated.

Latest Cybersecurity News, Vulnerabilities, and Technical Analysis Stay updated with the latest cybersecurity news, discover vulnerabilities, and explore technical analysis in our lab…