Treat cookies as SameSite=Lax by default if no SameSite attribute is specified. Developers are still able to opt-in to the status quo of unrestricted use by explicitly asserting SameSite=None. This feature is available as of Chrome 76 by enabling the same-site-by-default-cookies flag. This feature will be rolled out gradually to Stable users starting July 14, 2020. See https://www.chromium.org/updates/same-site for full timeline and more details.
See also: https://www.chromestatus.com/feature/5633521622188032 (Cookies marked SameSite=None should also be marked Secure.) “SameSite” is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt-into its protections by specifying a SameSite attribute. In other words, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default, while allowing sites that require state in cross-site requests to opt-in to the status quo’s less-secure model. In addition, forcing sites to opt-in to SameSite=None gives the user agent the ability to provide users more transparency and control over tracking. ******NOTE: There is currently a bug affecting Mac OSX and iOS which causes SameSite=None cookies to be inadvertently treated as SameSite=Strict and therefore not sent with cross-site requests. (See https://bugs.webkit.org/show_bug.cgi?id=198181) Until this is fixed, SameSite=None may not work properly on Safari.****** Note: Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention ("Lax + POST") will be removed in the future.
Status in Chromium
Consensus & Standardization
Last updated on 2021-01-25