Implement Sliding-Window Rate Limiting Middleware on API Endpoints

[DebasmitaBose0]

Problem

FastAPI endpoints executing forensic parsing, metadata extraction, and antivirus checks are computationally heavy processes that write chunks to temporary disk paths and spawn sub-processes. Currently, there is no rate limiting on the /api/ endpoints. A single malicious or misconfigured client could flood the server with heavy uploads, exhausting CPU cores, memory limits, and disk space (DDoS).

Current Behavior

• Every HTTP request to endpoints is processed instantly.
• Concurrent heavy uploads are scanned and run immediately in worker sub-processes without capacity limits.

Why This Improvement Is Needed

Digital forensics backends require enterprise-grade security boundaries. Rate limiting at the application layer protects key endpoints against automation abuse, ensures high availability, and prevents resource exhaustion bottlenecks.

Proposed Solution

1. Introduce a thread-safe RateLimiter class using a sliding-window token-bucket algorithm in Server/security.py.
2. Configure limit counts and windows (e.g. 30 requests / 60 seconds) through environmental variables.
3. Build a FastAPI HTTP middleware in Server/main.py intercepting all requests under /api/.
4. Parse client IPs (extracting from proxies via X-Forwarded-For when available) and enforce rate checks.
5. Return standard X-RateLimit-* and Retry-After headers on response, blocking exceeders with a clean 429 Too Many Requests.

Expected Outcome

• Hard API abuse boundaries established.
• Dynamic rate-limit telemetry returned to frontend developers.

Additional Notes

No third-party caching backend (like Redis) is required; fully implemented in-memory for zero-overhead deployment compatibility.