@neunzehnachtneun opened this Issue on May 1st 2019

Note: More info why this should be fixed in a soon Matomo release below: https://github.com/matomo-org/matomo/issues/14395#issuecomment-529198618

Hi together,
this is my first issue in this project, so hopefully I do it right.
I would like to request a new feature to improve privacy. At the moment it is possible yet to set the cookie lifetime to a shorter timespan and to set the cookie secure.
I suggest to also set the cookie attributes HttpOnly and SameSite=Strict, so privacy would be improved and cross site request attacks forgery could be prevented.

Thank you!

@fdellwing commented on May 1st 2019 Contributor

As far as I'm aware of every cookie that can be httponly is httponly. Can you show one that is not that way?

@tsteur commented on May 1st 2019 Member

What do you refer to here @neunzehnachtneun ? To the JS tracker? In JS you cannot set a cookie as httponly

@neunzehnachtneun commented on May 2nd 2019

Thank you for answering! Yes, I refer to the JS-Tracker and, yes, you are totally right. I read a bit about javascript and cookies and it's totally useless to set the cookie header to httponly.

But also I read about the cookie header 'samesite=strict', which is possible to use with javascript and which I would like to use with matomo. What do you think about that?

@fdellwing commented on May 2nd 2019 Contributor

While using samesite you need to really take care of your cookie domain or you will run into a hell of a lot of trouble. This is especially important if you use a reverse proxy.

(This does not mean I'm against it, but it might be a breaking change for some people.)

@tsteur commented on May 2nd 2019 Member

You would also need to have matomo running on the very same domain? not even a subdomain? or would a subdomain still work?

@MichaelRoosz commented on May 12th 2019 Contributor

samesite is a origin related setting and should be used with caution. it would have effects on the tracked data and most certainly break the 3rd party cookie in in many use cases

@Findus23 commented on September 8th 2019 Member

Seems like this is becoming far more important: Chrome is planning to make all cookies that don't have an explicit SameSite option have SameSite=Lax by default. At the moment it is an optional flag (#same-site-by-default-cookies), but chrome 80 (release in the beginning of January 2020) will have it enabled by default.
https://www.chromestatus.com/feature/5088147346030592

(Disclaimer: I haven't fully understood the topic and the explanations are all a bit vague, so this might be incorrect)
This means that if your Matomo is on matomo.someagency.example any request that isn't from the same site (so someagency.example or www.someagency.example) won't recieve any cookies. If you have Matomo installed on the same "site" as the website you are tracking (so a subdomain or subdirectory) nothing should really change.
But in every other change this will break some things. One I noticed that is especially critical is the opt-out iframe. I guess the same will also happen for widgets without token_auth.

Simply updating all cookies to add a SameSite=None flag won't help much as on one hand SameSite is a useful security feature as it makes CSRF attacks far harder and on the other hand there is a bug in all current Safari versions (iOS and MacOS) that causes them to interpret SameSite=None as SameSite=Strict which will break even more things.

Another related change is that starting in chrome 80 all cookies with SameSite=None and without the secure flag will be rejected completly. (https://www.chromestatus.com/feature/5633521622188032) So Matomo instances without HTTPS (I hope there are hardly any left) might have even more problems if we try SameSite=None.

More Details:
https://web.dev/samesite-cookies-explained

@MichaelRoosz commented on September 19th 2019 Contributor

When talking about the third party cookie (_pk_uid) and the opt out cookie, I guess the best setting for all setups with Matomo on its own (sub)domain is SameSite=None + secure. The Safari/iOS fix for SameSite=None will not be backported to iOS <13, so we should not write the SameSite attribute for ios and macos until most users are on a fixed version. This would mean that the third party feature and the opt-out iframe feature will require https. Which should not be an issue in 2019. If its possible an alternative solution for the opt out cookie on http should be implemented.

@tsteur commented on September 19th 2019 Member

We could possibly also detect some browsers and send different headers for them? But of course be hard to test and maintain it all etc. Might be worth for some very popular browsers/versions.

@fdellwing commented on September 20th 2019 Contributor
@MichaelRoosz commented on September 20th 2019 Contributor

Proposed values for the SameSite flag:

SameSite=None (but not for iOS or Safari on macOS):

  • Opt-Out IgnoreCookie (piwik_ignore)
  • 3rd Party Cookie (_pk_uid)

SameSite=Lax

  • PHP Session Cookie (MATOMO_SESSID) -> requires PHP >= 7.3: session.cookie_samesite=Lax
  • Language Manager Cookie (matomo_lang)
@MichaelRoosz commented on September 20th 2019 Contributor

Proposed values for the secure flag:

  • set if Matomo runs on https
  • not set if Matomo runs on http (maybe add some warning, that it will not work with Chrome >=80?)
@Findus23 commented on September 20th 2019 Member

@MichaelHeerklotz
Both sound good to me and are about what I would have suggested.
But this also means that we would need to make it very explicit that using Matomo without HTTPS means:

  • that features are broken
  • that it is highly likely that you are in violation of privacy laws.
@mattab commented on October 22nd 2019 Member

it would be great to fix this in the next minor release eg. 3.12.1 as we're starting to get reports that people see a a warning in their Chrome developer console:

A cookie associated with a cross-site resource at https://x.matomo.cloud/ 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 https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032"

@tsteur commented on November 10th 2019 Member

Not sure if this issue is maybe related? https://github.com/matomo-org/matomo/issues/15083

@Findus23 commented on November 10th 2019 Member

@tsteur I doubt this as #15083 also is reported in non-chrome browsers and I doubt many people are using Chrome Dev or Canary (two releases after the current one) which I think is the first one with this change.

@KokoKoder commented on November 15th 2019

Simply here to comfirm @MichaelHeerklotz proposition for default as value as they are in accordance with Chrome DevTools warning: "A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure"

@jackherizsmith commented on January 15th 2021

This still seems to be an issue, unless I have misunderstood something. Getting

A cookie associated with a cross-site resource at http://xxx.matomo.cloud/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure.

Could you advise on how best to proceed?

@tsteur commented on January 17th 2021 Member

@jackherizsmith can you maybe share with us on which page this is happening? Feel free to email us at support@matomo.cloud

This Issue was closed on January 8th 2020
Powered by GitHub Issue Mirror