The policies DefaultCookieLegacySameSiteSetting and CookieLegacySameSiteAllowedForDomains allow you to revert the SameSite behavior of cookies (possibly on specific domains) to legacy behavior. All cookies that match a domain pattern listed in CookieLegacySameSiteAllowedForDomains (see below) will be reverted to legacy behavior. For cookies that do not match a domain pattern listed in CookieLegacySameSiteAllowedForDomains, or for all cookies if CookieLegacySameSiteAllowedForDomains is not set, the global default setting will be used. If DefaultCookieLegacySameSiteSetting is set, its value will determine the global default setting. If DefaultCookieLegacySameSiteSetting is not set, the user's personal configuration will determine the global default setting. The SameSite attribute The SameSite attribute of a cookie specifies whether the cookie should be restricted to a first-party or same-site context. Several values of SameSite are allowed:
See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 for the definition of the SameSite attribute. See https://web.dev/samesite-cookies-explained/ for a more detailed explanation of the SameSite attribute with examples. Legacy SameSite behavior As of Chrome 80, a cookie that does not explicitly specify a SameSite attribute will be treated as if it were "SameSite=Lax". In addition, any cookie that specifies "SameSite=None" must also have the Secure attribute. (See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.5 for the definition of the Secure attribute.) Reverting to the legacy SameSite behavior causes cookies that don't explicitly specify a SameSite attribute to be treated as if they were "SameSite=None", i.e., they will be sent with both same-site and cross-site requests. In addition, reverting to the legacy behavior removes the requirement that "SameSite=None" cookies must also specify the Secure attribute. Configuring CookieLegacySameSiteAllowedForDomains In this policy setting, you can list specific domains for which legacy SameSite behavior will be used. The domain of a cookie specifies those hosts to which the cookie will be sent. If the Domain attribute of the cookie is specified, then the cookie will be sent to hosts for which the specified Domain attribute is a suffix of the hostname, and reversion to legacy SameSite behavior will be triggered only if the value of the specified Domain attribute matches any of the patterns listed in this policy setting. If the Domain attribute of the cookie is not specified, then the cookie will only be sent to the origin server which set the cookie, and reversion to legacy SameSite behavior will be triggered only if the hostname of the origin server matches any of the patterns listed in this policy setting. See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.3 for the definition of the Domain attribute. Example 1: If the Domain attribute of the cookie is set to "Domain=example.com", the cookie will be sent when making HTTP requests to example.com, www.example.com, or www.corp.example.com. To revert to legacy behavior for such a cookie, use the pattern '[*.]example.com' or 'example.com'. The value of the Domain attribute (example.com) will match either of these patterns. Even though the cookie would be sent to www.example.com, the pattern 'www.example.com' will NOT match such a cookie, because the Domain attribute value (example.com) does not match the pattern 'www.example.com'. Example 2: If the Domain attribute of a cookie set by www.example.com is not specified, the cookie will be sent only when making HTTP requests to www.example.com. The cookie will not be sent when making HTTP requests to example.com or sub.www.example.com. To revert to legacy behavior for such a cookie, use the pattern 'www.example.com' or '[*.]example.com'. The origin server's hostname (www.example.com) will match either of these patterns. Note that patterns you list here are treated as domains, not URLs, so you should not specify a scheme or port. |
|
|