The SameSite Cookie Default: How Chrome 80 Broke Logins in Early 2020
When Chrome 80 rolled out starting in February 2020, most users noticed nothing. A meaningful number of site operators noticed a great deal: embedded payment iframes stopped completing, single sign-on redirects silently failed to preserve sessions, and third-party widgets that relied on cross-site cookies broke without any error message a typical user would understand. The cause was a single, deceptively small change to how Chrome handled cookies that didn’t explicitly declare their own cross-site behavior.
What Actually Changed
Cookies have always carried an optional SameSite attribute, defined originally to help prevent cross-site request forgery (CSRF) attacks. It takes three possible values:
SameSite=Strict— the cookie is only sent when the request originates from the same site as the cookie’s domain. The most restrictive option.SameSite=Lax— the cookie is sent for same-site requests and for top-level navigations (like clicking a link) to the cookie’s domain, but not for background cross-site requests like those made by an embedded iframe or an image tag.SameSite=None— the cookie is sent on all requests, same-site or cross-site, regardless of context. This is the behavior needed for legitimate cross-site use cases: embedded payment widgets, third-party login flows, and analytics that need to correlate a user across sites.
Before Chrome 80, a cookie set without any SameSite attribute at all was treated as if it were SameSite=None — sent everywhere, in every context, by default. Chrome 80 flipped that default: a cookie with no explicit SameSite attribute is now treated as SameSite=Lax. And critically, using SameSite=None explicitly now also requires the Secure attribute, meaning the cookie must only be set over HTTPS.
The change itself is a handful of words in a specification. The blast radius was enormous, because a huge fraction of the web’s cookies had never bothered to set a SameSite attribute at all — there had never been a reason to, since the old default already did what most cookie-setting code implicitly assumed it would do.
Why This Broke So Much
The failure mode was almost always the same shape: a service that legitimately needs its cookie sent in a cross-site, embedded context — a payment processor’s iframe, a “login with X” identity provider redirect, a customer-support chat widget embedded on a client’s site — had never explicitly marked its cookies SameSite=None; Secure. Under the old default, that omission didn’t matter, because the implicit behavior already matched what was needed. Under the new default, the same cookie was silently downgraded to same-site-only, and any cross-site request carrying it simply arrived without the cookie attached.
The word “silently” is doing a lot of work in that sentence. There was no error thrown, no obvious console warning in earlier Chrome versions, and no user-visible failure message. A login flow would simply appear to succeed and then behave as if the user were logged out on the next page. A payment iframe would load but the transaction would fail validation. Developers debugging these issues in the first weeks after rollout were often chasing a problem with no clear symptom pointing at cookies at all.
Chrome’s own developer relations team had published guidance and a migration timeline well in advance, and DevTools added explicit console warnings flagging cookies that would be affected by the change before it shipped by default. But advance notice reaches engineering teams actively watching browser release notes; it does not reach the long tail of smaller sites, agency-built embeds, and legacy systems running with minimal active maintenance — which is exactly where most of the breakage concentrated.
The Pandemic Complication
The rollout timing collided with an event nobody could have planned around. Chrome 80 began its staged rollout in early February 2020, and by mid-March, as the scale of the COVID-19 pandemic became clear, Google made an unusual public announcement: it would temporarily roll back enforcement of the new SameSite default, reverting affected cookies to the old implicit behavior, specifically to reduce the risk of unexpected breakage during a period when critical online services — government benefit portals, healthcare systems, remote work and video-conferencing tools suddenly handling enormous new load — could least afford an unrelated compatibility incident on top of everything else happening.
Google’s own communication around the rollback was explicit that this was a temporary, exceptional measure driven by the pandemic’s timing rather than a reversal of the underlying decision. Enforcement was restored later in 2020 once the immediate crisis period had passed, and the SameSite=Lax default has remained Chrome’s standard behavior since. The episode is a useful reminder that even a well-planned, well-communicated browser platform change can run into circumstances entirely outside any engineering team’s control, and that browser vendors do sometimes prioritize short-term stability over a shipped security improvement when the stakes of getting the timing wrong are high enough.
The Security Rationale
The change wasn’t cosmetic. SameSite=Lax as a default is a meaningful CSRF mitigation applied automatically, web-wide, without requiring every site operator to individually add cookie attributes correctly. CSRF attacks work by tricking a logged-in user’s browser into making a request to a target site — a bank transfer, an account change — using the ambient authentication cookie that browser already holds for that site. If the cookie simply isn’t sent on cross-site requests by default, a large class of CSRF attacks stops working without the target site doing anything special.
This is the same logic that later motivated broader third-party cookie restrictions: a security or privacy property that depends on every individual site correctly opting in is much weaker in practice than one applied as a safe default, with sites required to explicitly opt out (via SameSite=None) only when they have a genuine cross-site need.
What Site Operators Actually Had to Do
The fix, once identified, was usually simple: audit every cookie the application sets, and for any cookie genuinely needed in a cross-site context, add SameSite=None; Secure explicitly. For cookies that only needed same-site behavior — the vast majority, in practice — no change was needed at all, since the new Lax default matched the intended behavior.
The harder part was the audit itself. Identifying every cookie a non-trivial web application sets, including ones set by third-party scripts, analytics tags, and embedded widgets outside the application’s own codebase, required more cross-team coordination than the one-line fix suggested. Organizations running federated login, embedded payment processing, or extensive third-party widget integration generally had the roughest migrations, since those are exactly the legitimate cross-site cookie use cases the change was designed to require explicit handling for.
The Longer Arc
Chrome 80’s SameSite default was one step in a much longer campaign against ambient, implicit cross-site cookie behavior — a campaign that continued with more aggressive proposals to restrict third-party cookies entirely, and with Google’s later, repeatedly-delayed Privacy Sandbox initiative aimed at replacing third-party cookie tracking use cases with narrower, privacy-preserving APIs. It’s a different mechanism from the browser-level opt-out signals we’ve covered elsewhere and from Firefox’s approach of blocking known trackers by default, but the underlying philosophy is the same: changing a default that almost nobody had configured explicitly can have far more real-world impact than adding a new opt-in feature ever does, precisely because defaults are what most of the web actually runs on.
FAQ
Did the SameSite change break every site with cookies? No. It only affected cookies that needed to be sent in a genuine cross-site context, like an embedded iframe or cross-site form submission, and had never explicitly set a SameSite attribute. The majority of cookies on the web are used same-site and were unaffected.
What is the difference between SameSite=Strict and SameSite=Lax? Strict blocks the cookie from any cross-site request, including top-level navigation from an external link. Lax allows the cookie on top-level navigations (like clicking a link to the site) but blocks it on background cross-site requests such as those from an embedded iframe or image tag. Chrome’s new default uses Lax specifically because it’s less disruptive to normal link-clicking behavior while still blocking the CSRF-relevant background request patterns.
Why does SameSite=None require the Secure attribute? Because a cookie sent on every cross-site request, unrestricted, is exactly the kind of cookie that would be most damaging if intercepted over an unencrypted connection. Requiring HTTPS for any cookie that opts back into full cross-site sending closes off that specific risk.
Did other browsers adopt the same default? Firefox and other Chromium-based browsers moved toward similar SameSite defaults following Chrome’s lead, though rollout timing varied by browser. The industry direction converged on Lax-by-default as the sensible baseline once Chrome demonstrated the migration was survivable at scale.
Is this the same thing as blocking third-party cookies entirely? No — a related but distinct effort. The SameSite default change restricts cookies from being sent in specific cross-site contexts unless explicitly permitted; it does not stop third-party cookies from being set or read altogether. Full third-party cookie restriction is a separate, more aggressive step that came later and generated a different, larger set of migration challenges for the advertising ecosystem specifically.
