Every analytics snippet ships its site ID in public page source, so treating it as a credential is theater. The real question is what an attacker can do with it, and the answer should be: nothing that matters. This post lays out the layered model, public identifiers with origin allowlists in front, signed server APIs behind.
This article is a stub.
The outline below is what the finished post will cover. Want it sooner? Tell us.
01Public by design
- Why the site ID can't be secret and shouldn't pretend to be
- Documented abuse of leaked analytics write keys
02Origin allowlists as the browser-side gate
- What Origin checks do and don't stop
- Server-to-server spoofing and why rate limits back the allowlist
03The server API is a different animal
- HMAC request signing: method, path, timestamp, body hash
- Replay windows and why a NaN timestamp once disabled ours (a war story)
- One identical 401 for every failure, because distinct errors are an oracle
04Rate limiting that survives deployment reality
- Per-IP before auth, per-key after
- The reverse-proxy trap: when every request looks like it came from nginx
Research brief
“Security models for public analytics tracker identifiers (site IDs, write keys): origin-allowlist enforcement, abuse cases of leaked write keys, HMAC request signing for server APIs, rate limiting strategies, and published postmortems of analytics-endpoint abuse.”
The deep-research question this article will answer, sources cited in the finished piece.