Skip to content
Home » Blog » Science » Computer Science » Web Development » Google Chrome’s SameSite Cookie Fix for your Website

Google Chrome’s SameSite Cookie Fix for your Website

6 minute read

Google Chrome is releasing Chrome 80 this month and it includes an update regarding the SameSite cookie attribute. If your website has anything that depends on cookies for functionality, this may affect your website for those that use this popular browser. So what do you need to know? What can you do? Don’t panic! Breathe, and then let me walk you through some steps on debugging your own site to know if you need to take action, and then what that action looks like!

Step 1: Check for the SameSite Cookie Warning

I noticed a few months ago that Chrome has been providing warnings on this update in the console, so I’ve modified my cookie setting function way back then. However, unless you spend a lot of time in the console as I do, you’re not likely to notice it. You’ll need to do this part on a computer or laptop.

  1. First, go to your website in the Google Chrome browser.
  2. Press the F12 key on your keyboard (or first press the “Fn” key and then the F12 key if using a laptop) to open up the debugger.
  3. Along the top, click on the tab labeled “Console”. This is where client-side scripts are logged to (think Javascript).

Hopefully, there isn’t a whole lot to see here, but what you’re looking for are any yellow warning messages with this kind of verbiage:

A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies> and see more details at <URL> and <URL>.
SameSite cookie warning (grouped)
A cookie associated with a resource at http://doubleclick.net/ was set with 'SameSite=None' but without 'Secure'. A future release of Chrome will only deliver cookies marked 'SameSite=None' if they are also marked 'Secure'. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.
SameSite cookie warning (single)

If you see a warning like the screenshot above labeled “grouped” where there is an arrow with a number on the top left, that means it’s grouped several warnings together. Click on it to expand and see all the individual errors.

What you need to know is if your website is responsible for the offending cookie. The first sentence, “A cookie associated with a cross-site resource at __________ was set without the SameSite attribute,” specifies the domain name that created the cookie, and if that domain name is your website, then you’ve got some fixing to do!

If it’s not, then find out who owns that domain and contact them or submit a support ticket to let them know their product/service needs to be updated. If it’s a Google website (like analytics.google.com or doubleclick.net) or another popular service (like MailChimp’s list-manage.com or my favorite icon provider fontawesome.com), then it’s likely that they’re already aware of the situation. It doesn’t hurt to still contact them and ask them a friendly, “what’s up?”

Need help finding out if you are responsible for updating cookies or contacting vendors? Contact me!

Step 2: Audit Your Cookies

If any warnings in step 1 say the cookie was made from your website, then it is your responsibility to fix it! There are a few things to understand about Google’s update and what your options are for updating your cookie appropriately.

The short non-developer explanation is that each cookie is a pair with a “key” and a “value” and it’s usually used for some important purpose. For example, if your website has subscribers, you might have some way of automatically identifying people to keep them logged in where the key might be something like my_website_user_id and the value would be whatever is assigned to that user, like 12345.

The SameSite attribute (defined in RFC6265bis) that is the fuss of this update can be set to one of three options:

  1. Setting it to Strict communicates to the browser that the cookie can only be “read” by the website that is specified by its path attribute.
  2. Setting it to Lax communicates to the browser that the cookie can only be “read” by the website or any of its subdomains that is specified by its path attribute.
  3. Setting it to None, or not including the attribute at all, communicates to the browser that the cookie is sent in a third-party context and any website can “read” this cookie.

Basically, just make a list of all the cookies your website is setting (the list will be in your console from step 1), discover what the purpose of each one is, and then decide on which of the three settings is most appropriate for each one.

Step 3: Update Your Cookies

If you’re not a developer and don’t have one to help you fix your cookies, please contact me! I’d love to help!

For the more developer-ish quickie fix explanation, if you’re creating a cookie in JavaScript, it probably looks something like this (though hopefully not because you wouldn’t hard-code something like this, would you? No, no you wouldn’t):

document.cookie = "my_website_user_id=12345; expires=Thu, 01-Jan-70 00:00:01 GMT; path=/";

You just need to include the SameSite attribute and value, as well as marking it as Secure because the second part of the warning had this sentence, “A future release of Chrome will only deliver cookies with cross-site requests if they are set with ‘SameSite=None’ and ‘Secure’.”

Though I will also mention it here that marking it with “Secure” means the cookie will only work with websites that have a valid SSL certificate applied. If you mark your cookies as secure but your site is accessed with http:// it the beginning instead of https://, the cookie will not be available. Before updating your cookies, it’s best to first secure your site by installing a valid SSL and adding redirects from http to https to ensure your cookies continue to work for all site visitors.

(Psst, if you host your website with me, your SSL certificate is free! Just sayin’)

So modifying the above snippet, if we’re keeping it the same as the implied None, would be updated to look like this:

document.cookie = "my_website_user_id=12345; expires=Thu, 01-Jan-70 00:00:01 GMT; Secure; SameSite=None; path=/";

If you’re creating cookies with PHP, it depends on your version. But for the sake of laziness efficiency, here’s one that includes a PHP version check (credit to Marty Aghajanyan):

if( PHP_VERSION_ID < 70300 ) {
    //For versions less than PHP 7.3, abuse the "path" parameter because it does not escape semicolons
    setcookie(
         "my_website_user_id",
         "12345",
         "Thu, 01-Jan-70 00:00:01 GMT",
         "/; Secure; SameSite=None"
     );
} else {
    //For PHP version 7.3+, use an array to specify these attributes
    setcookie(
         "my_website_user_id",
         "12345",
         array(
            'expires' => "Thu, 01-Jan-70 00:00:01 GMT",
            'path' => "/",
            'domain' => "",
            'SameSite' => "None",
            'Secure' => "Secure"
         )
    );
}

And there you have your SameSite cookies and can eat them too.

Nobody has commented on this yet, be the first!