Is there any URL based verification for the traffic sent?

[WebDev-Akhil]

I can see that the traffic sent from my vercel preview links counts as traffic in Umami Dashboard. (more info: Vercel is a hosting platform and generates random URLs for preview links)

Correct me if I'm wrong but what is stopping a bad actor from copying my website's Umami Analytics script tag from from the chrome browser console and put in some fake website and send false traffic?

[TreyWW]

Yeah, I've just installed umami and realised from any site I can just copy the <script> and put it even on local host and the stats still go up...
Surely the bare minimum security should be checking if the sender site matches the website domain in settings?

[suiluj]

this would be great!

Alternative analytics platforms already support this feature:

• Fathom analytics allowed domain
• plausible allowed domains
  • plausible github issue regarding this topic

[TreyWW]

Also by the seems of it, even adding the umami official one used by their docs on my local host seems to give me "200 ok".
E.g. swapping

<script defer="" data-website-id="86d4095c-a2a8-4fc8-9521-103e858e2b41" data-domains="umami.is" src="/a/script.js"></script>
for
<script defer="" data-website-id="86d4095c-a2a8-4fc8-9521-103e858e2b41" src="https://umami.is/a/script.js"</script>

Whether this actually works I'm not too sure, but it's a very concerning security issue if it does

Edit: Should the logic be here?

umami/src/lib/session.ts

Line 48 in 784237b

const validHostnameRegex = /^[\w-.]+$/;

[mikecao]

This is simply how HTTP requests work. There is no inherent security because you can pass whatever headers you want to make the request.

[TreyWW]

Ah, I guess so. Its just odd that out of the box theres 0 verification, at least with e.g google analytics they verify that the sent from header is the site. There may still be ways to bypass that (im not too sure how they figure out the site url exactly) but would be nice to have some security

[boehs]

Browsers do insert this header. Servers don’t. If a bad actor did this client side, it would be hard to retroactively remove what they did due to the distributed hash information. If they did it server side, you could just remove the rows with a hash matching their IP, Therefore, this browser only protection is still important

[suiluj]

I noticed this problem too.

At least it would be great to rotate the website id from time to time.

Idea: website id rotation

workflow static websites

• trigger generation of new website id via umami api endpoint
• build website with new website id

workflow normal websites

• for normal website you could create a cronjob that rotates the website_id

---

Of course really bad actors could still get the new id every time but it would take more effort.