Implement Rate Limiting on All Endpoints (Not Just Auth) in the api folder

[grantfox-oss]

Priority: Medium
Files: src/app.module.ts, controllers
Description:

• Extend the existing rate limiting to cover all endpoints
• Configure appropriate limits for different endpoint types (read vs write)
• Add @SkipThrottle() decorator to endpoints that shouldn't be throttled (if any)
  Acceptance Criteria:
• All endpoints have appropriate rate limits
• Rate limiting works correctly
• No false positives or performance issues

---

[Glam26]

I'd like to work on this.

My approach would be:

• Review the current throttling configuration in src/app.module.ts and identify which controllers/endpoints are already protected.

• Classify endpoints into read-heavy and write-heavy operations and apply appropriate limits for each category rather than using a single global threshold.

• Audit authentication, health, webhook, and internal endpoints to determine whether any should use @SkipThrottle(), documenting the rationale for each exception.

• Add or update tests to verify:

  • Read endpoints respect their configured limits.
  • Write endpoints enforce stricter limits.
  • Skipped endpoints remain accessible when expected.
  • Rate limiting returns the correct response without affecting normal traffic patterns.

• Validate there are no false positives during typical API usage and ensure the configuration does not introduce noticeable performance overhead.

I'll also provide a short summary in the PR explaining the chosen limits and why each endpoint category uses them.

[Tobi-8]

hey maintainer, i just looked at the description and i had have experience in resolving this issue, kindly assign

[Babigdk]

I’d like to work on extending the current rate limiting setup to cover all endpoints in the application.

I will configure different limits based on endpoint type—stricter limits for write operations and more relaxed limits for read-heavy routes—to balance protection and usability.

I’ll also review the codebase and apply @SkipThrottle() only where it’s truly needed to avoid unnecessary throttling on internal or safe endpoints.

Finally, I’ll ensure the setup is tested so rate limiting works correctly without causing false positives or impacting performance.

[Yasir-TechGuy]

Hi Maintainer, Please Assign me this issue I'm interested in this issue because rate limiting is a key layer of API security and reliability. I have experience working on backend systems, API testing, and security-focused improvements, and I'm confident in implementing balanced rate limits that protect the application without impacting legitimate users. I'll ensure the solution is well-tested, performant, and aligned with endpoint usage patterns.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@Glam26's PR #523 was approved and merged by @Qoder-Undefined.

🏆 @Glam26: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (716 total points). Track your full progress on GrantFox.

👏 Great work, @Glam26! Keep contributing to MERIDIAN-CITY.