As part of ongoing efforts to improve browser safety, the Chrome development team announced a new implementation of SameSite attributes and requirements regarding cookies. The new code uses a more stringent ‘secure-by-default’ model for getting and setting values on the browser. The difference is an enforced SameSite value of ‘None’ plus Secure in third-party cookie contexts. This change also makes it easier for browser creators to grant the user options to manage third-party cookies and first-party cookies independently.
First party cookies frequently hold persistent state information for features such as recognizing the browser for express logins on sites users have previously logged into. Users might like to keep these but remove third-party cookies, which are typically trackers, due to privacy concerns. It would be nice to be able to do so without the tedium of working through an enormous list of both familiar and unfamiliar websites.
The ‘secure-by-default’ model
For developers, the important part of this news is mainly the different handling of third-party cookies as part of the secure-by-default trend in the browser space. Firefox and Edge are joining Chrome in implementing the new policy beginning in February. Safari’s recently announced Intelligent Tracking Prevention (ITP) is similar, but may handle SameSite settings differently than as explained here.
Secure-by-default is a defensive posture where only the least amount of trust (none) is established between parties at first contact. Escalation of privilege for access to sensitive information, such as retrieving cookie values in a third-party context, requires explicit permission settings before the browser will send cookie values in request headers to the website. First-party cookies have an established infrastructure privilege for transmission.
YouTube cross-site cookie example
Imagine a user who logs into YouTube where a session cookie is set in the first-party context. The new policy requires a SameSite attribute value of ‘None’ along with a ‘Secure’ declaration (SameSite=None; Secure) to explicitly allow YouTube to retrieve its cookie values within a third-party context, as for the embedded player published on an external blog. When cookies are set and values are retrieved in this way — sometimes in first-party and other times in third-party contexts — they are classified as cross-site cookies.
Cross-site cookies allow a YouTube widget to recognize a logged-in user’s browser and activate the ‘view later’ option in the video player window as a frame embedded in an external site. As long as the original cookie was set with ‘SameSite=None; Secure,’ then YouTube widgets will continue to function normally. YouTube may already be doing this in readiness for the upcoming change and Google recommends that you prepare, too.
Readiness for change
When implemented, the new SameSite policy mechanism will require third-party cookies to self-identify and be transmitted over TLS (https://) connections, or else they will be subject to restrictions by the secure-by-default fallback model. The SameSite=None attribute requires the Secure designation, or the directive is rejected and requests are treated as SameSite=Lax (where cookie values are not sent in third-party contexts).
Scattered amongst various Google resources are some tips for how to test your implementation of SameSite=None with or (wrongly) without the Secure declaration. Dedicated tests for this behavior use Chrome or Firefox configuration settings. For Chrome 76+ it is enabled with the following address:
chrome://flags/#cookies-without-same-site-must-be-secure
Firefox 69+ in its about:config settings you want to set the following:
network.cookie.sameSite.noneRequiresSecure
You can also conduct tests and view SameSite console warnings in browser developer tools as you implement SameSite in the third-party context.
Cross-site request forgery
In the realm of application security, cross-site request forgery (CSRF) is dangerous. The new cookie policy can play a role in limiting (but not eliminating) successful attacks using known CSRF vulnerabilities. The traditional openness of the web allows cookie values to be sent liberally and it is therefore routine for attackers to evaluate network communications looking for access through an insecure implementation of cookies by a website.
Never store application secrets in cookie values.
Although application security is beyond the scope of this article, anti-CSRF hidden tokens in your web forms can help ensure that action requests are from valid users and not from an imposter who hijacked a user’s active session at a public hotspot.
None of these tactics are failsafe, however.
SameSite cookie setting guide
There are three possible values for SameSite: Strict, Lax, and None. Thus far we’ve been primarily dealing with the None setting for third-party access. Not all settings are relevant in all contexts. To help sort this out, and dispel confusion around the meaning of the ‘None’ value, this short guide may be helpful:
When setting first-party cookies for an application that never needs to retrieve cookie values from within a third-party context, use Strict. This setting is the most secure insofar as your cookie values are not sent in contexts where third parties reference your assets and can thereby retrieve values simply by including an image of yours in their HTML.
The Lax setting is the same as Strict except for when a third-party back link click to your application conducts a TLS (https://) secure request. The incoming headers for such visits will come complete with cookie values from third party pages that reference your assets alongside clicked links. Cookie values get sent so that your application can act accordingly and personalize settings for your user.
A setting of None plus Secure (SameSite=None; Secure) is the most liberal setting which allows access to cookie values in third party contexts as long as communications are handled over TLS (https://) connections. The Secure declaration is a requirement with this setting. This is the one best suited only for cross-site cookies such as is the case with YouTube’s widget distribution model.
Beware the complexities
As mentioned above, Safari has not announced the implementation of behavior for ‘SameSite=None; Secure’ cookies as Chrome, Firefox, and Edge are planning. It is important to adopt strategies that catch and handle exception cases for Safari and others. Older Chrome, Firefox, and Edge browsers are incompatible with the SameSite change, as well. The general advice is to look to the future and make SameSite-incompatible cases the exceptions for special handling, and not the other way around.
There are specific concerns for iOS and Android App developers who will need to declare the SameSite settings, including assurance that TLS (https://) secure connections take place using the native WebView API for each platform. And finally, Single Sign On (SSO) enterprise IT admins may need to revert company-wide Chrome instances to legacy behavior in order for SSO to function until a plan can be drafted for moving to updated services.
