DeveloperChrome 80 enforces SameSite-by-default cookie handling
Chrome 80 just changed how cookies work, and it might break your apps. Cookies without explicit SameSite attributes now default to Lax, which blocks cross-site requests. If you rely on cross-site authentication, embedded widgets, or federated login flows, you need to audit your cookies and explicitly mark the ones that need cross-site access with SameSite=None; Secure.
Verified for technical accuracy — Kodi C.
Remember when cookies just worked? Chrome 80, released February 4, 2020, changed that. The new SameSite cookie policy breaks things that developers have relied on for years—and that is intentional. Google's pushing the web toward better privacy defaults, even if it means your third-party integrations suddenly stop working.
What actually changed and why you should care
Chrome 80 treats cookies without an explicit SameSite attribute as SameSite=Lax by default. Previously, cookies with no SameSite attribute were sent with all requests, including cross-site requests. Now they are only sent with same-site requests and top-level navigation GET requests. This sounds technical, but the impact is immediate: many third-party integrations, embedded content, and cross-site authentication flows break.
The reasoning is straightforward: cookies sent automatically with cross-site requests enable cross-site request forgery (CSRF) attacks and enable pervasive tracking across the web. By restricting cross-site cookie behavior by default, Chrome forces developers to be explicit about which cookies should be accessible cross-site—and requires Secure flag for any cookie that needs cross-site access.
If you are running ads, analytics, embedded payment forms, social login, or any integration that relies on cookies being sent cross-site, this affects you. The days of "it just works" cookies are over.
The three SameSite values you need to understand
SameSite=Strict means cookies are only sent with requests originating from the same site. Period. No exceptions. This is the most secure option but breaks legitimate use cases like clicking a link from an email to a site where you are logged in—you'll appear logged out because your session cookie was not sent with that cross-site navigation.
SameSite=Lax (the new default) allows cookies to be sent with top-level navigations using safe HTTP methods like GET. This preserves the "click a link and stay logged in" experience while blocking cookies on cross-site POST requests, embedded iframes, and AJAX calls. For most session cookies, Lax provides reasonable security without breaking basic functionality.
SameSite=None means cookies are sent with all requests, including cross-site requests—the old behavior. But here's the catch: Chrome 80 requires SameSite=None cookies to also have the Secure flag, meaning they only work over HTTPS. If you need cross-site cookies, you must be explicit about it and you must serve your site securely.
What is breaking and how to diagnose it
The most common breakage patterns involve third-party embeds: payment processors in iframes, social media widgets, chat widgets, and analytics tracking. If users report that login states are not persisting, embedded content is not working, or integrations are failing, SameSite is your prime suspect.
Chrome DevTools is your diagnostic friend. Open the Application panel, look at Cookies, and check for warnings about SameSite. Console warnings will also flag cookies that are being blocked due to missing SameSite attributes or missing Secure flags. Document these findings before deploying fixes.
Third-party services you integrate with may need updates. Contact vendors whose embeds are breaking—many released updates specifically for Chrome 80 compatibility. Do not assume the problem is on your end without checking vendor documentation first.
Fixing your own cookies
For first-party session cookies, SameSite=Lax is usually the right choice. It provides CSRF protection while maintaining expected user experience for navigation. Update your session cookie configuration explicitly rather than relying on defaults that may differ across browsers.
For cookies that genuinely need cross-site access—authentication for embedded widgets, cross-domain single sign-on, legitimate tracking use cases—set SameSite=None and Secure. Test thoroughly, because you are explicitly opting out of browser protections.
Be systematic about your cookie audit. List all cookies your application sets, understand the purpose of each, and determine appropriate SameSite values based on actual requirements rather than convenience. Document decisions so future developers understand why specific values were chosen.
The broader context: privacy is eating the web
Chrome's SameSite changes are part of a larger trend. Safari's Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection, and upcoming Chrome third-party cookie deprecation all point in the same direction: browsers are now protecting users from tracking, even when it breaks developer expectations.
If your business model depends on cross-site tracking, this is an early warning. The technical mechanisms that enabled pervasive tracking are being systematically restricted. Adapt your analytics and advertising strategies now rather than scrambling when third-party cookies disappear entirely.
For security practitioners, SameSite-by-default is a significant CSRF mitigation. While you still need proper CSRF tokens for sensitive operations, the baseline protection is now much stronger than it was. Update your threat models accordingly.
Practical implementation checklist
- Audit all cookies your application sets and document their purposes and cross-site requirements.
- Set explicit SameSite attributes on all cookies rather than relying on browser defaults that may change.
- Use SameSite=Lax for session cookies unless you have specific cross-site requirements.
- For cookies requiring cross-site access, set both SameSite=None and Secure flags.
- Test in Chrome 80+ with DevTools open to identify blocked cookies and console warnings.
- Contact third-party vendors whose embeds are breaking and request updated integration guidance.
- Update security documentation to reflect improved CSRF baseline from SameSite defaults.
- Plan for future browser changes that will further restrict cross-site cookie access.
The web is getting more privacy-protective, one browser change at a time. Chrome 80's SameSite changes will not be the last disruption, but they are a clear signal about where browser vendors are heading. Developers who adapt now will have smoother transitions as privacy restrictions continue tightening.
Continue in the Developer pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Secure Software Supply Chain Tooling Guide
Engineer developer platforms that deliver verifiable provenance, SBOM distribution, vendor assurance, and runtime integrity aligned with SLSA v1.0, NIST SP 800-204D, and CISA SBOM…
-
AI-Assisted Development Governance Guide
Govern GitHub Copilot, Azure AI, and internal generative assistants with controls aligned to NIST AI RMF 1.0, EU AI Act enforcement timelines, OMB M-24-10, and enterprise privacy…
-
Developer Enablement & Platform Operations Guide
Plan AI-assisted development, secure SDLC controls, and runtime upgrades using our research on GitHub Copilot, GitHub Advanced Security, and major language lifecycles.
Coverage intelligence
- Published
- Coverage pillar
- Developer
- Source credibility
- 73/100 — medium confidence
- Topics
- Chrome 80 · SameSite · Cookies
- Sources cited
- 3 sources (blog.chromium.org, chromereleases.googleblog.com, iso.org)
- Reading time
- 5 min
Cited sources
- SameSite cookie changes in February 2020 — Chromium Blog
- Stable Channel Update for Desktop — Google Chrome Releases
- ISO/IEC 27034-1:2011 — Application Security — International Organization for Standardization
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.