What this usually means
The SameSite attribute on a cookie instructs the browser whether to send that cookie with cross-site requests. When set to Strict or Lax, and the request originates from a different site (top-level navigation or subrequest), the cookie is withheld. Modern browsers (Chrome 80+, Firefox 79+) treat cookies without explicit SameSite as Lax by default. This breaks many existing flows that rely on cookies being sent in cross-origin contexts, such as third-party widgets, cross-domain embeds, or OAuth redirects. The key non-obvious aspect is that 'same-site' is determined by registrable domain (eTLD+1), not by origin—so subdomains are same-site, but different TLDs are cross-site. Also, SameSite=None requires Secure flag; otherwise it's ignored.
The first ten minutes — establish facts before touching code.
- 1Open Chrome DevTools (F12) → Application → Storage → Cookies. Check the SameSite column for the cookie in question. Note: 'Lax' or 'Strict' means it won't be sent cross-site.
- 2Use the Network tab to inspect a failing request. Look at Request Headers: if Cookie header is missing, the browser blocked it. Also check the 'Initiator' tab for 'cross-site' warnings.
- 3Run curl with the cookie to see if the server accepts it: curl -v --cookie 'name=value' https://api.example.com/endpoint. If that works, it's a browser SameSite issue.
- 4Test in incognito mode—if it works, the browser likely has a cached stricter policy or existing cookies with SameSite=None without Secure.
- 5Check the server's Set-Cookie header in response: ensure SameSite attribute is present and set correctly (None for cross-site, Lax for most same-site). For None, Secure must be true and HTTPS must be used.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchChrome DevTools → Application → Storage → Cookies: list all cookies with their SameSite values
- searchChrome DevTools → Network → select failing request → Headers → Request Headers: check if Cookie is present
- searchChrome DevTools → Network → select failing request → Headers → Response Headers: look for Set-Cookie
- searchServer-side logs: check if the server is receiving any cookies in the request header
- searchCDN or proxy logs (Cloudflare, Fastly): some CDNs can strip or modify cookies based on SameSite
- searchBrowser console: warnings like 'A cookie associated with a cross-site resource was set without the SameSite attribute'
- searchThird-party cookie blocking settings: chrome://settings/content/cookies (Chrome) or edge://settings/content/cookies
Practical causes, not theory. These are the things you will actually find.
- warningCookie set without SameSite attribute, defaulting to Lax in Chrome 80+, blocking cross-site subrequests
- warningSameSite=None set but Secure flag missing, causing browser to reject the cookie entirely
- warningServer sets SameSite=Strict on a cookie needed for cross-site OAuth redirect (GET) because Strict blocks top-level navigations
- warningCross-site request from a subdomain that is actually different site (e.g., app.example.com vs api.other.com), but developer assumed subdomain is same-site
- warningCookie domain attribute too narrow (e.g., set for 'api.example.com' but request from 'www.example.com' is same-site but cookie not sent due to domain mismatch)
- warningBrowser extensions or privacy settings enforcing strict SameSite (e.g., Chrome's 'Block third-party cookies' overrides SameSite=None)
Concrete fix directions. Pick the one that matches your root cause.
- buildSet SameSite=None; Secure for cookies that must be sent cross-site. Ensure the response is over HTTPS.
- buildFor same-site cookies, use SameSite=Lax (default) or Strict if appropriate. Verify the site determination: different subdomains are same-site, but different TLDs are not.
- buildIf OAuth redirect fails, set the session cookie with SameSite=Lax (allows top-level GET navigations). Do not use Strict for redirect flows.
- buildIf the cookie is needed in iframes or subrequests, set SameSite=None; Secure and ensure the parent page is HTTPS.
- buildUse the Cookie Prefix __Host- or __Secure- to enforce Secure and Path=/ for extra safety, but ensure compatibility.
- buildTest with curl and then with browser DevTools to isolate the issue. Use Chrome's 'SameSite by default cookies' flag to test old behavior.
A fix you cannot prove is a guess. Close the loop.
- verifiedAfter fix, clear cookies for the site and re-test the flow. Check in DevTools → Application → Cookies that the SameSite column shows the expected value.
- verifiedIn Network tab, confirm the Cookie header is present on the failing request. Also verify Set-Cookie response header includes SameSite=None; Secure.
- verifiedRun the failing scenario in an incognito window to ensure no stale cookies interfere.
- verifiedTest in multiple browsers (Chrome, Firefox, Safari) to confirm consistent behavior.
- verifiedCheck the server logs to ensure the cookie is being received and processed.
- verifiedUse a test like 'https://samesite-sandbox.glitch.me/' to simulate cross-site requests and verify cookie behavior.
Things that make this bug worse or harder to find.
- warningSetting SameSite=None without Secure on HTTP—browsers will reject it.
- warningChanging SameSite to Lax/Strict globally without understanding which requests need cross-site cookies (e.g., login redirects).
- warningAssuming subdomains are cross-site—they are same-site, so Lax works. But different TLDs are cross-site.
- warningForgetting to update the cookie domain attribute when moving from one subdomain to another.
- warningApplying SameSite=Strict on session cookies that are needed for top-level navigation from external sites.
- warningRelying on third-party cookies being enabled by default—privacy trends are blocking them more.
OAuth Login Fails After Chrome Update to SameSite Default Lax
Timeline
- 09:00Users report they cannot log in via Google OAuth. They click 'Sign in with Google', are redirected to Google, then back to our site but remain unauthenticated.
- 09:15I check logs: callback endpoint receives no session cookie. Browser console shows 'A cookie associated with a cross-site resource...' warning.
- 09:30Check DevTools Application → Cookies: session cookie has SameSite column empty (defaults to Lax). But OAuth redirect is a top-level navigation from Google to our site.
- 09:45I mistakenly think Lax should allow top-level GET. Then notice cookie is not sent because the redirect is cross-site (from accounts.google.com to oursite.com). Lax allows top-level navigations, but only if the cookie is set by the same site. Our session cookie was set in a cross-site context (during login initiation from our site via a popup). Actually, the cookie was set from our domain, but the navigation is top-level from Google. That should work.
- 10:00I test with curl: the cookie works. I then test with a simple cross-site request from a test page: cookie not sent. Then I realize the cookie's Domain attribute was set to 'app.oursite.com' but the redirect goes to 'oursite.com' (different subdomain? Actually same domain but different subdomain is same-site). Wait, domain mismatch? No, it's same-site.
- 10:15I finally check the Set-Cookie header from the server: it's missing SameSite attribute entirely. Browser defaults to Lax. But Lax should allow top-level GET. The issue is that the cookie was set during the OAuth initiation which was a cross-site POST? Actually, the initiation is from our site, so same-site. I'm stuck.
- 10:30I read Chrome's SameSite update blog: 'Lax will not be sent on POST requests from cross-site'. But our OAuth callback is a GET. Then I notice the cookie is set with Path=/api. The callback URL is /oauth/callback. That matches Path. So why not sent?
- 10:45I create a minimal reproduction. I find that the cookie is not sent because the 'site' for the cookie is determined by the top-level site at the time of the request. The cookie's Domain is not set, so it defaults to the host that set it. The callback request is to oursite.com, but the referrer is accounts.google.com (cross-site). Since SameSite=Lax, the cookie is NOT sent for cross-site subrequests? Wait, top-level navigation is allowed. But DevTools shows the request is a navigation (type 'document'), but the cookie is still missing.
- 11:00I discover the real cause: The cookie is set with Secure flag but the callback URL is HTTP (our nginx redirects HTTPS to HTTP internally?). Actually, the request is HTTPS, but the cookie might have been set via HTTP? No. I check: the Set-Cookie header includes Secure but the SameSite is missing. In Chrome, if SameSite is missing and Secure is present, it defaults to Lax. So it should work.
- 11:15Finally, I see it: The cookie was set by a script on our site (JavaScript) with document.cookie. That script was running in a cross-origin iframe? No. But the cookie's domain was set to '.oursite.com' which includes the subdomain. The request is to 'oursite.com' (no subdomain). That should match. But wait: the cookie was set from a page on 'app.oursite.com'. The domain attribute was '.oursite.com', so it's a domain cookie. That should be sent to 'oursite.com' because it's a subdomain? Actually, a cookie with domain=.oursite.com is sent to all subdomains, including the apex? No, the apex is included. So that's fine.
- 11:30I give up and set SameSite=None; Secure on the session cookie. Then it works. But I want to understand why Lax failed. I later read that Chrome 80+ treats cookies without SameSite as Lax, but also that Lax+POST may block? But this is GET. Then I find bug: The cookie had a Path that was set incorrectly to '/api' but the callback is '/oauth/callback'. That's why it wasn't sent. The Path must match exactly. I had changed the Path earlier and forgot. So the root cause was Path mismatch, not SameSite. But the SameSite default caused confusion.
The incident started with user reports that Google OAuth login stopped working after a Chrome update. I immediately suspected the new SameSite defaults. I opened DevTools and saw the session cookie had no SameSite attribute, defaulting to Lax. I assumed that top-level navigations are exempt, so the cookie should be sent on the OAuth redirect. But it wasn't.
I spent hours debugging: checking curl, testing with incognito, verifying Secure flag, and even considering browser bugs. I tried setting SameSite=None; Secure and it worked, confirming a SameSite issue. But I wanted Lax to work to maintain security. I created a minimal reproduction and discovered that the cookie's Path was set to '/api' but the callback was at '/oauth/callback'. The Path mismatch caused the cookie to be omitted. The SameSite default Lax was a red herring.
The lesson: always check the cookie's Path and Domain first. SameSite changes only affect cross-site behavior; Path/Domain are still checked. Also, when debugging, systematically verify all cookie attributes before blaming SameSite. In the end, I corrected the Path to '/' and kept SameSite=Lax. The OAuth flow worked perfectly.
Root cause
Cookie Path attribute mismatch: cookie set with Path=/api but OAuth callback at /oauth/callback, causing browser to omit the cookie regardless of SameSite.
The fix
Changed the session cookie Path to '/' and verified SameSite=Lax (default) works for top-level navigation from cross-site.
The lesson
When a cookie is not sent, always check Path and Domain before SameSite. Use DevTools to see cookie attributes. Isolate with curl and a simple test page. Don't assume SameSite is the only cause.
The SameSite specification uses the concept of 'site' based on the registrable domain (eTLD+1). Two URLs are same-site if they share the same eTLD+1. For example, https://app.example.com and https://api.example.com are same-site because both have eTLD+1 = example.com. However, https://example.com and https://example.co.uk are cross-site because eTLD+1 differ (example.com vs example.co.uk). Note that the scheme (http vs https) does not affect site—it's only about domain.
Subdomains are always same-site. Ports and paths are irrelevant for site determination. This is often misunderstood; developers think different subdomains are cross-site, but they are not. However, third-party services (like Google, Facebook) are always cross-site unless you own the domain.
The SameSite attribute can be Strict, Lax, or None. Strict: cookie never sent on cross-site requests (including top-level navigations). Lax: cookie sent on cross-site top-level navigations that use a 'safe' HTTP method (GET, HEAD, OPTIONS, TRACE). None: cookie sent on all cross-site requests, but requires Secure flag and HTTPS. If SameSite=None is set without Secure, the cookie is rejected by the browser.
Additionally, the cookie's Path attribute must match the request URL's path. The Domain attribute specifies which hosts can receive the cookie. If Domain is not set, it defaults to the exact host that set it (no subdomains). If Domain is set, it must start with a dot, and the cookie is sent to all subdomains of that domain. For example, Domain=example.com (without dot) is invalid in some browsers; always use Domain=.example.com. Also, the Path and Domain are checked before SameSite—if they don't match, the cookie is not sent regardless of SameSite.
To isolate if SameSite is the issue, first test with curl: curl -v --cookie 'name=value' https://yoursite.com/endpoint. If the server responds correctly, the issue is likely browser-side. Next, create a simple HTML page that makes a fetch request to your endpoint and observe if cookies are sent using DevTools. You can use the 'schemeful same-site' test: if you have both HTTP and HTTPS versions, note that SameSite treats them as same-site if the scheme is the same? Actually, scheme does not affect site, but Secure flag requires HTTPS.
You can also use Chrome's flag `#same-site-by-default-cookies` to disable the new behavior and test with old defaults. But this is only for testing; do not rely on it for production.
Frequently asked questions
What is the difference between SameSite=Lax and SameSite=Strict?
SameSite=Strict: the cookie is never sent on cross-site requests, including top-level navigations. This means if a user clicks a link from an external site to your site, the cookie won't be sent. SameSite=Lax: the cookie is sent on cross-site top-level navigations that use a safe HTTP method (GET, HEAD, etc.). This allows links and redirects to work while still protecting against CSRF from subrequests like images or iframes. For most login flows, Lax is sufficient.
Why is my SameSite=None cookie not being set?
The most common reason is that the Secure flag is missing. SameSite=None requires the cookie to be marked Secure and transmitted over HTTPS. If you set SameSite=None without Secure, the browser will ignore the cookie. Also, ensure the response is over HTTPS. Another reason: the cookie's Domain or Path may conflict, or the cookie size exceeds the browser limit (usually 4KB). Check the Set-Cookie header in DevTools to see if it's rejected.
Does SameSite affect cookies in iframes?
Yes. If your page embeds an iframe from a different site, and you need to send cookies from that iframe to its server, those cookies must have SameSite=None; Secure to be sent with the iframe's requests. If the cookie has SameSite=Lax or Strict, the browser will not send it for cross-site subrequests (like iframe loads). This is a common issue with third-party widgets or payment forms.
How can I debug SameSite issues in Safari or Firefox?
In Safari, go to Develop → Show Web Inspector → Storage → Cookies. You can see the SameSite column (though older versions may not show it). In Firefox, open Developer Tools → Storage → Cookies, and look for the SameSite column. Both browsers may have different default behaviors: Safari historically blocked third-party cookies by default, while Firefox uses Total Cookie Protection. For testing, use Chrome's detailed SameSite warnings in the Console.
Can I use SameSite cookies with APIs that are called from mobile apps?
SameSite is a browser concept; mobile app HTTP clients (like OkHttp, URLSession) do not enforce SameSite. However, if your mobile app uses a WebView to display web content, the WebView may enforce SameSite like a browser. For native API calls, cookies are sent as usual. But if you use cookie-based auth in a mobile app, you should consider token-based auth instead, because cookies may not be stored reliably.