Hi all,
Apologies in advance for the long post.
We are considering to build a Matomo integration for our CMS.
For simplicity, let me explain this with an analogy: We are a SaaS somewhat similar to wordpress.com (the SaaS, not the self-hosted!). Our customers have an account, enter content in our CMS which gets then published to something such was bob.ourawesomecms.com
.
The system is designed to be simple and we want to prevent any form of script injection by our publishers. One reason: Readers/commenters of the blog can have an account with us as well, and it is in our interest to protect their personal data and identity (e.g. by not exposing this in the full extent to the publisher).
To integate a Matomo tracking, we are planning to add a configuration to our CMS which allows Bob to input the following two settings:
matomo_url
(either pointing tohttps://bob.matomo.cloud
orhttps://matomo.bobsmatomoinstance.com
)site_id
(not relevant in the following)
Based on this information we build the appropriate tracking JS and inject it into the pages shown on Bob’s site. Very simplified like so:
<script src="${matomo_url}/matomo.js" async defer></script>
// Matomo initialization here
So far so good.
The issue, about which I am concerned, arises, if Bob decides to misuse the Matomo integration for not doing Matomo tracking at all, but injecting his own evil script:
- Put a fake
matomo.js
onhttps://this-is-not-a-matomo-instance.com/matomo.js
- The script would e.g. record user activity such as entering username and password of the commenters (who should stay anonymous to Bob) and submit this back to
https://this-is-not-a-matomo-instance.com
In other words: We cannot really ensure that the matomo_url
is a real Matomo instance or something just pretending to be a Matomo. Any attempts on our end to ensure that matomo_url
is an actual Matomo instance (by calling an API endpoint, etc.) can obviously easily circumvented (or later be switched).
The only mitigation which I see: Just do not load matomo.js
from any user-supplied source, but instead serve it from our own trusted source. However, the FAQ advise against this:
- Local copy of piwik.js outdated Some users make a local copy of piwik.js on a different server than their Matomo installation. This is not officially supported and causes issues when the piwik.js bundled with Matomo is updated and not compatible with the previous version (for example, this is the case in Matomo 0.5.5). Please check that your Matomo JS tracking code is exactly the one given in the Matomo admin screen.
- So, is this still a no-no? (considering the text speaks of v0.5.5 from long ago)
- Is it doable if we ensure that the matching version (v2, v3, or v4) of the JS is used? E.g. by adding a version toggle to the configuration?
- Or is v4 of the script even backwards-compatible to older Matomo versions?
Or are there any other recommended approaches to this?
Many thanks for your attention!