SameSite Cookie Bypasses: CSRF-Adjacent Bugs for Bounty Hunters
SameSite=Lax is not shorthand for “CSRF fixed.” It changes when browsers attach cookies to cross-site requests, and the details around “site,” navigation, request method, and cookie age create useful edge cases. Hunters get into trouble when they report the cookie flag itself instead of a state change.
Your target is a request that performs a sensitive action with ambient cookies despite the intended cross-site boundary.
Same-site is wider than same-origin
Two origins can be same-site while differing by subdomain, port, or scheme rules. app.example.com and blog.example.com are usually same-site. If the blog has XSS, an attacker can issue requests that browsers treat differently from a page on attacker.net.
That makes sibling domains worth mapping. Marketing CMS, user-content hosts, abandoned subdomains, and redirectors can become SameSite gadgets. The main app may have perfect output encoding while a forgotten sibling supplies the launch point.
Do not confuse this with CORS. CORS controls whether script can read a response; SameSite controls cookie attachment. A blind state-changing request may be enough.
Lax and top-level navigation
Lax cookies are commonly sent on top-level cross-site navigations using safe methods, especially GET. If an endpoint changes email, joins an organization, or toggles security settings through GET, a simple link can trigger it.
Method overrides widen the search:
GET /account/email?_method=POST- Form field
_method=PUT - Path suffixes or framework headers that convert a nominal GET
- GraphQL-over-GET mutations accepted by a permissive gateway
Use a second account and a reversible field. Show the victim visiting a normal attacker page, then show the saved change. A cookie appearing in DevTools without impact is only configuration trivia.
Newly issued cookie window
Chrome's Lax-by-default behavior has historically allowed recently created cookies on some top-level POST flows. Login CSRF chains can exploit this: force or entice a fresh session cookie, then immediately submit the state-changing request.
Browser behavior evolves, so record the exact browser version and cookie attributes rather than copying an old PoC. Test with a clean profile. Existing cookies, extension interference, and previous site interaction can change results.
On-site gadgets
An open redirect on the target site may turn a cross-site start into a same-site navigation, though redirects do not magically bypass every cookie rule. Client-side redirects are often more interesting because the browser may classify the resulting request from a trusted site context.
Sibling-domain XSS is stronger. From promo.example.com, script can submit a form to app.example.com; the request may carry Strict or Lax cookies because it remains same-site. Origin-based CSRF tokens can still stop it, which is why cookie flags should be one layer, not the whole defense.
Make the report survive triage
Include the cookie's full Set-Cookie attributes, browser version, attack origin, navigation type, raw state-changing request, and before/after evidence. Explain whether user interaction is a click, form submission, or none. Severity follows the action: newsletter preference is not account takeover; disabling MFA or changing recovery email may be.
Recommended fix: CSRF tokens bound to the session, Origin/Referer validation, no state changes over GET, and re-authentication for critical settings. Use SameSite as defense in depth, with Secure and HttpOnly where applicable.
PortSwigger's SameSite bypass guide tracks these browser patterns. Retest against current releases—the browser, not the blog post, decides whether the cookie travels.