Analytics endpoint checked the event name and waved the payload through

Flow

From a name list to a contract per event

Each step ends in something a test or a review can confirm.

1. 1Write a contract⌄

   List the fields each event may carry, with a type and a range. Check: an undeclared field is dropped.

2. 2Shrink risky fields⌄

   Folder paths become a yes-or-no flag, error text becomes a category. Check: no field accepts free text.

3. 3Identity from the login⌄

   The server adds who sent it. Check: a request that tries to set identity loses to the session.

4. 4Blocklist as an alarm⌄

   Optional name-based drop with a counter. Check: it is never the only guard.

5. 5Collect less in the tool⌄

   Stop gathering the folder and the raw error. Check: the tool's sample events match the contract.

6. 6Bad-payload tests⌄

   Extra field, wrong type, long value, fake token. Check: each is dropped or refused.

The analytics endpoint checks the name of each event and lets the rest of the event through. Whatever the event carries ends up in an outside analytics tool, next to the user's email.

The endpoint is how my command-line tool reports milestones like setup started and upload finished. I found this by reading the code changes, not by digging through stored data, so I can say what could leak, not what did.

Login, rate limit, size cap, name list

The endpoint does the basic things well. You have to be logged in. It limits how often one user can call it. It caps how big a request can be. It turns away any event name that isn't on a short list. It even logs only the names of the fields, never their values.

Any field, any value

The fields inside an event are a different story. Any short field name with any value is accepted, copied into the event, and sent on with the user's email and organization attached. So the name list decides which events exist, and nothing decides what they hold.

The tool sends more than you'd guess. Every event carries machine details like the OS, runtime and memory. A comment calls part of that anonymous, but it travels with an email, so it isn't. The upload event includes the folder being scanned. A failed upload sends the raw error message. Folder names often hold usernames or client names, and error messages often quote whatever broke.

A guard that didn't survive review

For a while there was a scrubber. It dropped fields with names like "password", cut long text short, and capped the number of fields. A review removed it, and the commit doesn't say why. A comment at the top of the file still says values are size-limited. They aren't, beyond the overall request cap.

It wasn't much of a guard anyway. It only looked at field names, so a secret under an innocent name got through, and it never read the text itself.

The same review fixed one real thing: the tool now sends its setup-started event only after you've logged in, and skips sending when it holds no credentials. It also deleted a browser comment saying click tracking was off, even though the settings below it turned it on. Click tracking, session recording and a profile with name, email and avatar are all still on.

What I'd build instead

If you're building something like this, give each event a contract, a declared list of fields where each one has a type and a range:

• Choices become a fixed set of words.
• Counts become rough buckets instead of exact numbers.
• Folder paths go away, or become a yes-or-no "used the default" flag.
• Error text becomes a short category like "network" or "parse".
• Identity comes from the login session, never from the request.

Anything not declared gets dropped before it's sent. Other parts of my server send events straight to the analytics tool without touching this endpoint at all, so a contract on the endpoint would only ever cover the command-line tool. A name-based blocklist can stay behind that as an alarm, not as the main guard. And the tool itself should stop collecting the folder and the error text, no matter what the server does.

Then test it. Send each event its declared shape and expect it accepted. Send an extra field, a wrong type, a too-long value and a fake token, and expect each one dropped or refused. The endpoint shipped without any test like that.