A Stranger Tried The Door — So We Built A New One

🔍 What David Found

The disclosure was simple and embarrassing: four paid downloads were public.

If you knew (or guessed) the filenames — godmode.zip, godmode-plus.zip, godmode-evolution-QUICKSTART.md, one-shot-scripts.zip — you could just curl them off the static site. No auth, no signing, no purchase check. The folder was a corkboard.

Two extra paths were also leaking under obfuscated names: /dl-a8f3c9e2b714.skill and /dl-e7d4b1f06a39.md. Obfuscation was never the security model — it just slowed things down for anyone who didn't read the page source carefully.

🚪 The Old Door

The original setup was the cheapest possible: paid product files lived in the same /downloads/ folder as the free files. The website's checkout page sent the link to your inbox, and that was the whole gate.

The problem with sending a permanent link to a permanent file is that the file doesn't know who has the link. Once a single URL leaks — pasted in a Slack, screenshotted in a tweet, indexed by a crawler — the file is everyone's.

🔐 The New Gate

The fix was to build a gate that asks two questions on every request: did the right person ask for this? and did they ask for it recently?

The shape of the answer is a path-style HMAC signed URL. Each part of the path is a piece of evidence the gate checks before opening:

When the Worker sees a request, it runs four checks in order. The request fails on the first one that doesn't pass.

That's the entire gate. Sixty lines of JavaScript and a single shared secret on three places: the Worker, plus the two server-side endpoints that mint URLs (one for the npm MCP client, one for the browser dashboard).

🎮 Try The Gate

The interactive panel below is wired to the same logic the live Worker runs. Flip the switches to feed the gate different inputs — the URL on the right changes to match, and the verdict box shows what the Worker would return. (No real requests; this runs in your browser.)

What the demo shows that the static gate couldn't: every check is independent, and a leaked URL stops working five minutes after it was minted — even if every other field is perfect.

🔎 Verifying The Fix

Before declaring this done we ran a full pen test against the new gate. Sixteen probes covering replay, path traversal, method tampering, timing analysis, and signature forgery. Every adversarial input got a 403; every valid input got a 200.

🛡️ While We Were Here

You can't audit one corner of a site without looking at the rest. The same shape of bug — trusting the URL alone — might be hiding somewhere else. So we did a sweep across the supabase edge functions, Cloudflare workers, client JS, and the auth flows.

Result: the rest of the codebase is in better shape than the leaky folder was.

Stripe webhook signature is properly verified. Every privileged edge function checks a JWT before doing anything. The image-upload function verifies magic bytes server-side, not just MIME claims. Idempotency keys are baked into the purchase recording. None of these were rushed in after the disclosure — they were already there.

The two medium-priority items are both infrastructure-level hardenings rather than code defects, and they're already on the next sprint.

🎁 Thank You, David

Responsible disclosure costs the researcher time and asks them to trust us not to react badly. David spent both, and got nothing for it except the satisfaction of doing it right.

So we packaged up the /one-shot-scripts skill — the same protocol that ran most of the testing in this post — with a thank-you note, and sent it across. Small thing, but it's the kind of trade we want more of: a researcher tells us something, we fix it fast and quietly, and they get something useful back.

📝 Lessons Worth Repeating