feat: add per-IP rate limiting to /register and /federation

[devprom6]

Summary

Closes #252

Protect the API from spam and brute-force attacks by limiting requests per IP.

A dedicated ipLimiter is added in stellar-payment-platform/server.js that caps clients at 100 requests per 15 minutes per IP and responds with 429 Too Many Requests when the limit is exceeded. It is applied directly to the /register and /federation endpoints.

Unlike the existing global limiter (which keys by account id and can be bypassed by rotating addresses in the payload), this limiter keys strictly by client IP, so a single source flooding the endpoints is reliably blocked.

Changes

• Added ipLimiter (windowMs: 15 * 60 * 1000, max: 100) keyed by client IP, returning a RATE_LIMITED error body on exceed.
• Uses the existing Redis-backed RedisStore when available, with in-memory fallback.
• Applied ipLimiter as the first middleware on:
  • app.post('/register', ...)
  • app.get('/federation', ...)

Acceptance Criteria

• Limits to 100 requests per 15 minutes per IP
• Returns 429 Too Many Requests when exceeded
• Applied to /register and /federation

Notes

express-rate-limit and rate-limit-redis were already declared in stellar-payment-platform/package.json.

Test Plan

• Send >100 requests to /register and /federation from the same IP within 15 minutes and confirm a 429 response with a RATE_LIMITED body.
• Confirm legitimate clients under the threshold are unaffected.
• Verify RateLimit-* headers are present on responses.

[vercel]

@devprom6 is attempting to deploy a commit to the Abdulazeem's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@devprom6 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