How Chrome’s SameSite=Lax Default Changes Cross‑Site Cookie Behavior

The problem: unexpected authentication failures after a Chrome update

If you maintain a legacy widget that relies on a third‑party site automatically sending its session cookie with a cross‑site POST, you may have noticed users being logged out after Chrome 80 rolled out in February 2020. The symptom is a 401 or redirect to a login page even though the cookie is present in the browser’s storage.

Thesis

Chrome’s decision to treat cookies without an explicit SameSite attribute as SameSite=Lax removes the automatic inclusion of those cookies in unsafe cross‑site requests, which mitigates many CSRF‑style attacks while breaking sites that depended on the old implicit behavior.

What changed in Chrome 80

Starting with Chrome 80, the browser applies a default SameSite=Lax policy to any cookie that does not declare SameSite=None, SameSite=Strict, or SameSite=Lax. Under this rule:

• The cookie is sent with top‑level navigations (e.g., clicking a link) and with safe HTTP methods (GET, HEAD, OPTIONS) from a different site.
• The cookie is **not** sent with sub‑resource requests (images, scripts, iframes) or with unsafe methods (POST, PUT, DELETE) initiated from a different site.

This change reduces the attack surface for CSRF that relies on cookies being automatically added to cross‑site POSTs, while preserving common redirect‑based SSO flows that use GET navigation.

How to verify the effective SameSite setting

Open Chrome DevTools → Application → Cookies, select the domain, and look at the \"SameSite\" column. For a cookie that lacks an explicit attribute you will see the value \"Lax\".

You can also inspect the raw Set‑Cookie header in the Network tab: right‑click the response → Copy → Copy response headers and search for \"Set‑Cookie\". If the header does not contain SameSite=, the browser will treat it as Lax.

Worked example: making a cross‑site POST work

Suppose you control the API at https://api.example.com and you need a login widget hosted on https://widget.example.net to send a session cookie via POST.

1. On the server, set the cookie with both SameSite=None and Secure flags. In Node.js/Express:

res.cookie('sessionid', token, {
  httpOnly: true,
  sameSite: 'none',   // explicit None
  secure: true,       // required when SameSite=None
  path: '/',
});

Or, if you prefer to set the header directly:

Set-Cookie: sessionid=abc123; SameSite=None; Secure; Path=/; HttpOnly

2. From the widget page, make a fetch request:

fetch('https://api.example.com/login', {
  method: 'POST',
  credentials: 'include',   // send cookies
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ username: 'alice', password: '****' })
})
.then(r => r.json())
.then(console.log);

3. Verify in DevTools:

• Network tab → select the POST request → Headers → Request Headers → look for \"Cookie: sessionid=...\".
• If the header is present, the cookie is being sent; if absent, double‑check that the cookie truly has SameSite=None and Secure, and that the request is made over HTTPS.

Trade‑off and limitation

The SameSite=None; Secure setting opens the cookie to cross‑site transmission, which re‑introduces the potential for CSRF if the endpoint does not additionally validate the request (e.g., with a CSRF token or SameSite‑strict cookies for state‑changing actions). Therefore, you should:

• Keep SameSite=None only for cookies that are truly needed across sites (such as a federated login token).
• Protect any endpoint that consumes that cookie with additional anti‑CSRF measures or by ensuring the action is idempotent and safe.
• Regularly audit cookies in the Application panel to confirm none are unintentionally left with SameSite=None.

Actionable closing

1. Audit your site’s cookies: in Chrome DevTools, Application → Cookies, sort by the SameSite column and flag any that show \"Lax\" but are used in cross‑site POSTs.

2. For each flagged cookie, decide whether the cross‑site use is legitimate. If yes, update the server to emit SameSite=None; Secure; otherwise, modify the client to avoid the unsafe cross‑site request (e.g., use a GET redirect or proxy the request through your own origin).

3. After deploying the change, test in a recent Chrome version (≥80) by:

1. Clearing the cookie for the test domain.
2. Performing the cross‑site POST.
3. Confirming the Cookie header appears in the Network tab only when SameSite=None; Secure is set.

By aligning your cookie attributes with Chrome’s SameSite=Lax default, you eliminate unexpected authentication failures while still benefiting from the built‑in CSRF mitigation.