feat: add rate limiting to API endpoints to mitigate abuse and Dos

[dataCenter430]

Related Issue

Rate limiting – endpoints not rate-limited, increasing abuse and DoS risk.

Closes #1260

Description

Rate limiting is implemented for both the server and backend FastAPI apps using slowapi.

Changes

server/pyproject.toml Added slowapi>=0.1.9
backend/pyproject.toml Added slowapi>=0.1.9
server/app/rate_limit.py New rate limiting module
backend/app/rate_limit.py New rate limiting module
server/app/middleware/__init__.py Calls setup_rate_limiting(api)
backend/app/__init__.py Calls setup_rate_limiting(api)
server/app/controller/health_controller.py Added @limiter.exempt on health endpoint
backend/app/controller/health_controller.py Added @limiter.exempt on health endpoint
server/.env.example Added RATE_LIMIT_ENABLED, RATE_LIMIT_DEFAULT

Behavior

• Global limit: 100 requests per minute per IP (configurable via RATE_LIMIT_DEFAULT)
• Health endpoints (/health) exempted for health checks and load balancers
• Can be disabled with RATE_LIMIT_ENABLED=false
• Uses in-memory storage by default; SlowAPI also supports Redis for multi-instance deployments
• Returns HTTP 429 when limits are exceeded

Why it's better

• Abuse risk:
  • Before: Endpoints could be hit without limits
  • After: Requests per IP capped (default 100/min)
• DoS resilience:
  • Before: No protection against flood attacks
  • After: Traffic above limit rejected with 429
• Health checks
  • before: N/A
  • after: Exempt, so orchestration and monitoring stay reliable
• Configurability
  • before: N/A
  • after: Limits tunable via RATE_LIMIT_DEFAULT (e.g. 200/minute)
• Operational control
  • before: N/A
  • after: Can turn off with RATE_LIMIT_ENABLED=false if needed

To install dependencies and try it

cd server && uv sync # or: pip install slowapi
cd backend && uv sync # or: pip install slowapi

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Contribution Guidelines Acknowledgement

• I have read and agree to the Eigent Contribution Guideline

[bytecii]

I think we may not need this server side rate limiting? cc @Wendong-Fan

[dataCenter430]

Hi, @bytecii @Wendong-Fan thank you for catching this out. then I think it's essential for current Eigent codebase.
I added server‑side rate limiting as a lightweight safety net against abuse/DoS from desktop clients hitting a shared backend. Since Eigent can trigger expensive multi‑agent/LLM work per request, a single misbehaving client could saturate the API. This limiter is centrally configured via RATE_LIMIT_ENABLED / RATE_LIMIT_DEFAULT (see .env.example), leaves /health exempt, and can be turned off in environments where we don’t need it, so it gives us defense‑in‑depth with minimal downside.

Why it’s essential for Eigent specifically

• Untrusted / many clients: The Electron app talks to a shared API (https://dev.eigent.ai/api), so anyone with a client can hammer the backend; client‑side checks alone are easy to bypass.
• Expensive operations: Eigent runs multi‑agent / LLM workflows; one user can trigger lots of compute, DB, and external API calls, so unbounded request rates become real cost and stability risks.
• Central, configurable control:
  • Wiring is in server/app/rate_limit.py and server/app/middleware/__init__.py (setup_rate_limiting(api)),
  • Ops can tune or disable with RATE_LIMIT_ENABLED / RATE_LIMIT_DEFAULT in env, as documented in server/.env.example.
• Safety without breaking infra: Health checks are explicitly exempted, so orchestrators and docker-compose health probes keep working even when limits are enabled.

Therefore, I'd really appreciate if you have a deep considering.

[Wendong-Fan]

Thank @dataCenter430 for this PR and for thinking carefully about abuse/stability risks. After a thorough review, i think this feature may not for now, since at this stage, access already requires account registration/login, and each account is constrained by credits-based limits, most of our user are deploying&running Eigent locally so this is not a top priority right now

We’ll revisit and prioritize rate limiting if we see abnormal traffic patterns, open more public-facing endpoints, or move to broader gateway-level traffic controls, thanks again for the thoughtful contribution.

cc @bytecii

[bytecii]

close for now