Add rate limiting to the analytics events endpoint

[3m1n3nc3]

Description

POST /api/analytics/events accepts event tracking requests with no authentication and no rate limiting. Any client (or bot) can flood this endpoint with thousands of events per second, filling up the AnalyticsEvent table, degrading database performance, and skewing all metrics.

The userId field is taken from the x-user-id request header which is entirely client-controlled — any user can claim any other user's ID in analytics events.

More info

• Add IP-based rate limiting using a middleware solution (e.g. @upstash/ratelimit with Upstash Redis, or a simple in-memory token bucket for development).
• For the x-user-id header, replace the client-controlled header with a server-side session lookup: call auth() and use session?.user?.id instead of trusting the header.
• Consider batching analytics events on the client side (collect for 5s, then send a batch) to reduce request volume.

[ScriptedBro]

@ScriptedBro has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Hi, I am a full stack blockchain developer, and I’d like to apply for this issue.

I understand the problem is the unprotected analytics endpoint, the client-controlled user ID, and the risk of spammed event traffic affecting performance and data accuracy. I can add IP-based rate limiting, replace the header-based user ID with a secure server-side session lookup, and implement client-side batching to reduce request volume.

Thanks for your consideration.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ScriptedBro to this issue.

[KayProject]

@KayProject has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Hey Maintainer i would love to work on this issue
i have gone through the projects repository and seen the structure
i would add rate limiting to the analytics event endpoint and i would made sure this task is fixed in less than 24 hours

ℹ️ Repo Maintainers: To accept this application, review their application or assign @KayProject to this issue.

[drips-wave]

Congratulations, @KayProject! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on March 30, 2026.

🧑‍💻 @KayProject: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊