Ten Thousand Fake Viewers, No Account Needed

Most writeups end in stolen data. This one is different — nothing leaked. The damage here is to truth: a paid analytics product whose numbers anyone could fabricate.

The spark

Watching a video, I noticed the player firing view events to an analytics endpoint. The request had no authentication header at all. For a feature customers pay for — audience insights — that's a strange thing to leave open.

Digging in

The only thing the endpoint needed to attribute an event to a video was the video's ID — and that ID is public, because it's right there in the share URL. I forged a single play event for a real video with a made-up visitor ID. The server answered 200 and stored it. Then I sent ten in a row, fast. All 200. No rate limit.

Digging further: I could set unbounded watch-time and completion values, invent unlimited unique "visitors," and pad requests with junk fields — all accepted. The server validated the format of the IDs and nothing else.

The endpoint checked that my data was well-formed. It never checked that it was true, or that I had any right to submit it.

The exploit

A short script, no account, no cookies:

POST /analytics/event   { video_id: <public-id>, visitor_id: <random>, watch_ms: <anything> }
→ 200 {"stored": 1}   (repeat at will)

Point it at your own videos to inflate vanity metrics, or at a competitor's to pollute the paid Insights data they rely on.

Impact

An integrity attack on a paid product: fabricated views, unique-viewer counts and watch-time for any video, by anyone, at scale. When a company sells "trust our numbers," being able to forge those numbers is the whole ballgame.

The fix

Authenticate the telemetry, bind each event to a real viewing session server-side, rate-limit per source, and validate that the caller is actually entitled to report against that video.