Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,039 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

  • #2040 của @DPS0340 — đã đóng, không merge
  • #2072 của @Samarth1306w — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript
Lĩnh vực
api, backend, security

Hướng nghiên cứu

Bắt đầu với apps/web/lib/rate-limit.ts và kiểm tra cách RATE_LIMIT_IDS được tham chiếu bên ngoài phần khai báo của nó. So sánh hai route được nêu tên, apps/web/app/api/settings/billing/guest-checkout/route.ts và apps/web/app/api/analytics/track/route.ts, với apps/web/app/api/docs/ask/route.ts. Công việc được xem là hoàn tất khi các ID đã khai báo либо được các endpoint tương ứng gọi hoặc bị xóa, kèm theo một regression test ngăn các ID không được sử dụng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
23k
Fork
2k
Merge trung bình
13 giờ 2 phút
Pull request đã merge (30 ngày)
70

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.