7 of 13 RATE_LIMIT_IDS are declared but never called, so those endpoints have no rate limit

Inizia da apps/web/lib/rate-limit.ts e verifica come viene referenziato RATE_LIMIT_IDS al di fuori della sua dichiarazione. Confronta le due route indicate, apps/web/app/api/settings/billing/guest-checkout/route.ts e apps/web/app/api/analytics/track/route.ts, con apps/web/app/api/docs/ask/route.ts. Il lavoro è completato quando gli ID dichiarati vengono chiamati dai rispettivi endpoint oppure rimossi, con un test di regressione che impedisca la presenza di ID inutilizzati.

Summary

RATE_LIMIT_IDS in apps/web/lib/rate-limit.ts declares 13 rule ids, each with a doc comment naming the abuse it guards and a suggested window. 7 of them are never referenced anywhere in the codebase, so the endpoints they describe run with no rate limit at all.

Counting references outside the declaration file itself:

id	referenced	endpoint it names
AGENT_TOKEN_EXCHANGE	2	wired
AGENT_AUTHORIZATION	2	wired
AGENT_UNLOCK	1	wired
AGENT_LOOM_IMPORT	2	wired
TRANSLATE_TRANSCRIPT	1	wired
DOCS_ASK	1	wired
AUTH_OTP_VERIFY	0	Email OTP verification (brute-force guard)
AUTH_OTP_SEND	0	Email OTP / magic-link send (mailbomb + token-reseed)
LOOM_DOWNLOAD	0	Unauthed Loom download/convert (ffmpeg + memory DoS)
MESSENGER_MESSAGE	0	Anonymous support chat (Groq + Supermemory cost)
ANALYTICS_TRACK	0	Unauthed view tracking (Tinybird ingest + notifications)
GUEST_CHECKOUT	0	Unauthed guest checkout (Stripe object/cost abuse)
DESKTOP_LOGS	0	Unauthed desktop log to Discord forwarding (spam)

$ grep -rn AUTH_OTP_VERIFY apps packages --include='*.ts' --include='*.tsx' | grep -v lib/rate-limit.ts
(no output)

Same for the other six.

Why this is easy to miss

The file's own comment explains that a rule id with no matching Vercel Firewall dashboard rule fails open:

An ID that has no matching dashboard rule fails OPEN (checkRateLimit returns { rateLimited: false, error: "not-found" }) ... but it also provides no protection until the rule exists.

So there is already one silent-failure mode by design. A declared-but-uncalled id is a second one, and it is invisible from the dashboard side too: someone can create rl_guest_checkout in the Firewall, see it configured, and reasonably assume the endpoint is protected while no code ever calls it.

Two of the unprotected endpoints, checked

apps/web/app/api/settings/billing/guest-checkout/route.ts — no isRateLimited, no getCurrentUser, no auth of any kind. It reads priceId and quantity from the JSON body and calls stripe().checkout.sessions.create(...) directly. Anyone can create unbounded Stripe checkout sessions.

apps/web/app/api/analytics/track/route.ts — no isRateLimited. It uses provideOptionalAuth, so anonymous requests are expected, and it writes to Tinybird and can trigger createAnonymousViewNotification / sendFirstViewEmail. That is the exact combination the comment describes ("Tinybird ingest + notifications").

I checked those two by reading the route files. I did not audit all seven endpoints in the same depth, and I would rather say so than imply a completeness I have not verified.

What "wired" looks like, for reference

apps/web/app/api/docs/ask/route.ts is the model:

if (
  isLocallyRateLimited(ip) ||
  (await isRateLimited(RATE_LIMIT_IDS.DOCS_ASK, { headers: request.headers }))
) {
  return Response.json({ error: "Too many questions right now. Try again in a minute." }, { status: 429 });
}

Expected

Either each declared id is called at the endpoint it names, or the unused ones are removed so the constant does not imply protection that is not there.

Suggested direction

I would rather not blanket-wire seven endpoints in one PR without knowing the intent — some may be deliberately staged ahead of the dashboard rules being created. What I would suggest, and am happy to implement:

1. A cheap regression guard: a unit test that asserts every key in RATE_LIMIT_IDS is referenced at least once outside the declaration file. That turns "declared but never called" into a CI failure rather than something found by reading.
2. Then wire the endpoints, either all in one follow-up or one at a time, whichever you prefer to review.

I have (1) ready and will open a PR referencing this issue, since it is the part that holds regardless of what you decide about each endpoint. Tell me which of the seven you want wired and I will follow up.