Why cookies in Chrome matters more in security updates?

Cookies are one of the strategies which is available for including persistent state to websites. Over the years their skills have grown and evolved however left with some challenging legacy issues. To address this, browsers (including Chrome, Firefox, and Edge) are changing their behaviour to implement more privacy-preserving defaults.

What’s the difference between first and third-party cookies?

There are mainly 3 differences between a first and third-party cookie as explained below:

• Setting the cookie

First-party cookies are set through the publisher’s web server or any JavaScript loaded in the website. Third-party cookies can be set through a third-party server through the code loaded on the publisher’s website.

• Cookie availability

First-party cookies are accessible to the domain that created it. A third-party cookie available on any website that load the third-party server’s code.

• Browser support/blocking

First-party cookies are supported by way of all browsers and can be blocked or deleted by the user. Third-party cookies are supported through all browsers; however, many are blocking off the creation of third-party cookies by default. Users are also taking things into their own hands and deleting third-party cookies on their own.

Why you should not avoid the Not Secure Warning in Chrome?

Google Chrome will mark non-secure webpages containing password & credit card input fields as Not Secure in the URL bar.

• Enable warnings

To configure Chrome to exhibit the warning, follow below steps:

#1. Open chrome://flags/#mark-non-secure-as and set the non-secure origins as non-secure option to display a state when password / credit card fields are fetched on an HTTP page.

#2. Then launch your browser again.

You can see an instance of the browser’s warning as below.

When the Not Secure state is display, the Developer Tools console shows the message. This page includes a password or credit card input in a non-secure context. A warning has been added to the URL bar.

Image Source: Google Developers

• Resolve warnings

To make sure that the Not Secure warning is not displayed for your pages, you need to ensure that all forms containing  elements and any inputs detected as credit card fields are present solely on secure origins. This means that the top-level webpage should be HTTPS and, if the input is in an iframe, that iframe must additionally be served over HTTPS.

Warning: It is NOT acceptable to place an HTTPS iframe inside a HTTP page; the main page itself must be HTTPS as well.

If your website overlays an HTTPS login frame over HTTP pages…

Image Source: Google Developers

…you will need to change the site to either use HTTPS for the entire site or redirect the browser window to an HTTPS page containing the login form:

Image Source: Google Developers

Use HTTPS everywhere: Eventually, Chrome will exhibit a Not Secure warning for all pages served over HTTP, regardless of whether the webpage includes sensitive input fields. Even if you want to adopt more focused resolutions as mentioned above, you need to update website to use HTTPS for all webpages.

Why safe browsing lookups important in Chrome?

The team of www.chromium.org introduced 2 features that significantly improve phishing protections accessible to Google Chrome users:

Reducing the negative rate for Safe Browsing lookups in Chrome by launching real-time Safe Browsing lookups for users who have opted in to “Make Searches and Browsing better.” Early results are promising, with up to 55% more warnings shown as below image to users who had this safety turned on, compared to those who did not.

Image source: Chromium.org

A while ago www.chromium.org launched phishing protections to warn users who are syncing history in Google Chrome when they enter Google Account password into unauthorized phishing websites that try to steal their login information. With the Chrome 79, we improved this protection to everyone signed into Chrome, even if you have not enabled Sync. Further, this feature will work for all the passwords that user has stored in Google Chrome’s password manager which will show an estimated 10 times more warnings on regular basis.

How to Explicitly state cookie usage with the SameSite attribute.

The introduction of the SameSite attribute allows you to declare if your cookie should be restricted to a first-party or same-site context. It is helpful to understand exactly what ‘site’ means here. The site is the combination of the domain suffix and the part of the domain just before it. For example, the www.web.dev domain is part of the web.dev site.

Introducing the SameSite attribute on a cookie provides 3 different ways to control this behavior. One can choose to not specify the attribute or can use Strict or Lax to limit the cookie to same-site requests.

If you set SameSite to Strict, cookie will be sent in a first-party context. In user terms, the cookie will be sent if the website for the cookie meet the website currently shown in the browser’s URL.

When the user is on website, then the cookie will be sent with the request as expected. But, when following a link into your site, i.e. from another site or by an email, on that initial request the cookie will not be sent. This is good when cookies relating to functionality will be behind an initial navigation, such as changing a password or making a sale. If reader follows the link into the website, they want the cookie sent so their preference can be applied.

That’s where SameSite=Lax comes in by allowing the cookie to be sent with these main-level navigations.

Caution: Neither Strict nor Lax are a complete solution for site’s security. Cookies are sent as part of the user’s request & should treat them the same as any other user input. That means sanitizing and validating the input. Do not use a cookie to store information that is consider as a server-side secret.

How to do changes to the default behavior without SameSite

While the SameSite attribute is supported but it has unfortunately not been widely adopted by developers. The open default of sending cookies everywhere means all use cases work but leaves the user vulnerable to CSRF (Cross-Site Request Forgery) and unintentional information leakage. To encourage developers to state their intent & provide users with a safer experience. Better Cookies lays out 2 key changes:

• Cookies without a SameSite attribute will be treated as SameSite=Lax.
• Cookies with SameSite=None must also specify Secure, meaning they require a secure context.

Chrome implements these behaviors as of version 80.

Image Source: Web.dev

While this is calculated to apply a more secure default, one must ideally set an explicit SameSite attribute rather than relying on the browser to apply that. This makes one decide for the cookie explicit and improves the opportunity of a consistent experience across browsers.

Caution: The default behavior applied through Google Chrome is little bit more indulgent than an explicit SameSite=Lax as it will allow certain cookies to be sent on main-level POST requests. This is calculated as a temporary relief; one should still be fixing cross-site cookies to use SameSite=None; Secure.

Image Source: Web.dev

Test this behavior as of Chrome 76 by enabling chrome://flags/#cookies-without-same-site-must-be-secure

Apply this when setting new cookies & refreshing existing cookies even if they are not approaching their expiry date.

Both modifications are backwards-compatible with browsers that have correctly implemented the version of the SameSite attribute used before, or just do not support it at all. By applying changes to cookies, you are making their intended use explicit rather than relying on the default behavior of the browser. Likewise, any clients that do not recognize SameSite=None yet should ignore it and carry on as if the attribute was not set.

Warning: Several older versions of browsers including Google Chrome, Safari, and UC browser are incompatible with the new None attribute and may ignore/ restrict the cookie. This behavior is fixed in current versions. However, should check your traffic to determine what proportion of users are affected. You can see the list of known incompatible clients on the Chromium site.