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

[DPS0340]

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.

[linear]

CAP-765

[tembo]

Good analysis. There are two existing open PRs that implement the rate limiting for most of these endpoints:

• #1924 - Wires up AUTH_OTP_VERIFY and AUTH_OTP_SEND by wrapping the NextAuth catch-all route with per-email rate limiting on /callback/email and /signin/email. Also shortens OTP lifetime from 24h to 15 minutes.

• #1929 - Wires up LOOM_DOWNLOAD, MESSENGER_MESSAGE, ANALYTICS_TRACK, GUEST_CHECKOUT, and DESKTOP_LOGS. Also fixes a tenant-spoofing issue in the analytics route where tenantId was derived from client-supplied body.orgId/body.ownerId instead of the DB record.

Both PRs are currently in a "dirty" mergeable state (likely need rebasing on main). Together they would address all 7 unused IDs you identified.

For the regression guard idea in (1), the existing rate-limit references live in:

• apps/web/app/api/docs/ask/route.ts (lines 4, 119) - pattern to follow for the wiring
• apps/web/app/api/v1/[...route]/route.ts (multiple agent endpoints)
• apps/web/app/cli/authorize/page.tsx (line 98)

The isLocallyRateLimited + isRateLimited combo in apps/web/app/api/docs/ask/route.ts:115-121 is a good reference for how a dual local+Vercel guard works.

Note that issue #2010 (now closed) was related - it flagged that the Loom CSV import rate-limit check runs before the dedupe check, causing retries to burn quota on already-imported rows. That's in apps/web/actions/loom.ts around line 363.