feat(security): add payer-aware rate limiting (#670)

[nupedev]

Summary

Closes #670

Adds dual-mode rate limiting for anonymous traffic and authenticated payment or meter-management requests.

Changes

Anonymous /api traffic keeps an IP-based limiter with defaults of 100 requests per 15 minutes. Payment and meter-management routes now run a payer-aware limiter after express.json() and express.urlencoded() so the validated payer, owner, new_owner, or explicit X-Payer-Address identity is available.

Each payer receives a sliding one-hour bucket with a default maximum of 50 requests. The limiter uses Redis via ioredis when REDIS_URL is configured and falls back to a per-process in-memory Map when Redis is unavailable or not configured. Redis operations use an atomic sorted-set script, and a store failure fails over to memory rather than taking the API offline. Standard RateLimit-*, X-RateLimit-*, and Retry-After headers are returned for payer-scoped responses.

Verification

• npm test -- --run tests/rate-limit.integration.test.ts — 3 passed.
• git diff --check — passed.

The backend’s full TypeScript build still encounters unrelated pre-existing parser errors in src/index.ts and src/iot/bridge.ts; no diagnostics were produced by the focused rate-limit test.

[drips-wave]

@nupedev Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[nupedev]

Summary

Closes #670

Adds dual-mode rate limiting for anonymous traffic and authenticated payment or meter-management requests.

Changes

Anonymous /api traffic keeps an IP-based limiter with defaults of 100 requests per 15 minutes. Payment and meter-management routes now run a payer-aware limiter after express.json() and express.urlencoded() so the validated payer, owner, new_owner, or explicit X-Payer-Address identity is available.

Each payer receives a sliding one-hour bucket with a default maximum of 50 requests. The limiter uses Redis via ioredis when REDIS_URL is configured and falls back to a per-process in-memory Map when Redis is unavailable or not configured. Redis operations use an atomic sorted-set script, and a store failure fails over to memory rather than taking the API offline. Standard RateLimit-*, X-RateLimit-*, and Retry-After headers are returned for payer-scoped responses.

The ioredis dependency is added to backend/package.json. The existing backend/package-lock.json is intentionally not included in this PR because regenerating it with the repository’s current dependency state produced unrelated lockfile churn; maintainers can regenerate and review the lockfile as part of dependency installation.

Verification

• npm test -- --run tests/rate-limit.integration.test.ts — 3 passed.
• • git diff --check — passed.
    The backend’s full TypeScript build still encounters unrelated pre-existing parser errors in src/index.ts and src/iot/bridge.ts; no diagnostics were produced by the focused rate-limit test.