---
title: "Chrome’s Changes Could Break Your App: Prepare for SameSite Cookie Updates"
description: "Chrome's SameSite changes alter when third-party cookies are sent in cross-site requests, affecting sites that rely on embedded services, analytics, advertising, or other cross-domain functionality. Starting February 4, 2020, Chrome was to reject such cookies unless they were secured and assigned an appropriate SameSite value, as part of a secure-by-default model intended to reduce CSRF attacks, other vulnerabilities, and privacy leaks. The post explains first- versus third-party cookies, contrasts Strict, Lax, and None, and gives scenarios for selecting each setting; SameSite=None must be paired with Secure and HTTPS. It also recommends enabling Chrome 80 flags to test for errors, then updating application cookies or coordinating with third-party providers. Server-side support is noted for PHP, NodeJS, Python, Flask, and Ruby on Rails, with direct JavaScript cookie handling also mentioned."
---

# Chrome’s Changes Could Break Your App: Prepare for SameSite Cookie Updates

[Heroku](https://yomu.fyi/company/heroku) · Lenora Porter · Feb 4, 2020

**Type:** Tutorial

## Summary

Chrome's SameSite changes alter when third-party cookies are sent in cross-site requests, affecting sites that rely on embedded services, analytics, advertising, or other cross-domain functionality. Starting February 4, 2020, Chrome was to reject such cookies unless they were secured and assigned an appropriate SameSite value, as part of a secure-by-default model intended to reduce CSRF attacks, other vulnerabilities, and privacy leaks. The post explains first- versus third-party cookies, contrasts Strict, Lax, and None, and gives scenarios for selecting each setting; SameSite=None must be paired with Secure and HTTPS. It also recommends enabling Chrome 80 flags to test for errors, then updating application cookies or coordinating with third-party providers. Server-side support is noted for PHP, NodeJS, Python, Flask, and Ruby on Rails, with direct JavaScript cookie handling also mentioned.

## Context

Chrome announced a secure-by-default cookie model because cross-site cookie access can enable cross-site request forgery, other security vulnerabilities, and privacy leaks. The change also affects advertisers, publishers, and companies relying on cookies for targeting or cross-domain services.

## Approach / What changed

The post explains first-party and third-party cookies, compares the Strict, Lax, and None attributes, and maps each to common scenarios. It recommends testing with Chrome 80 flags, correcting cookie attributes, pairing SameSite=None with Secure, and contacting providers whose domains the site does not control.

## Takeaways

- SameSite=Strict blocks cross-site sharing, while SameSite=Lax permits cookies on top-level navigation using a safe method such as GET.
- SameSite=None preserves cross-site cookie use but must be combined with Secure; otherwise Chrome rejects the cookie.
- Testing involves enabling SameSite-related Chrome flags, checking for errors, and updating server-side or JavaScript cookie handling where needed.

**Tags:** [JavaScript](https://yomu.fyi/topic/javascript), [Privacy](https://yomu.fyi/topic/privacy), [Security](https://yomu.fyi/topic/security)

- Source: [Heroku](https://www.heroku.com/blog/chrome-changes-samesite-cookie)
- Source URL: https://www.heroku.com/blog/chrome-changes-samesite-cookie
- Ingested by Yomu: 2026-09-09T16:03:31.138Z

[Read original post](https://www.heroku.com/blog/chrome-changes-samesite-cookie)