Add configurable trusted-proxy depth validation to middleware/rateLimiter.ts

[Jagadeeshftw]

📌 Description

middleware/rateLimiter.ts keys buckets per client IP. If the service runs behind a load balancer, the effective client IP typically comes from X-Forwarded-For, which is trivially spoofable unless the app validates how many proxy hops it trusts and strips/ignores attacker-supplied prefix entries.

🧩 Requirements and context

• Add a trustProxyDepth (or reuse Express's trust proxy setting) so only the last N hops of X-Forwarded-For are honored.
• Document in config.ts/README how to configure this correctly for the deployment topology.
• Default to a safe, conservative setting (e.g. direct connection IP only) when unconfigured.

🛠️ Suggested execution

• Extend RateLimitOptions in middleware/rateLimiter.ts and loadConfig() in src/config.ts with the new setting.
• Add tests in middleware/rateLimiter.test.ts simulating spoofed X-Forwarded-For headers with and without the trust setting.
• Update README's rate-limiting section with a deployment note.

✅ Acceptance criteria

• Spoofed X-Forwarded-For values beyond the trusted depth don't bypass per-client limits.
• Config default is safe out of the box.
• Deployment guidance documented.

🔒 Security notes

Closes a rate-limit bypass vector where a client behind an untrusted proxy chain can forge its apparent IP to reset its own bucket.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[GBOYEE]

Hi team \u2014 I'd like to take this on (Add configurable trusted-proxy depth validation to middleware/rateL...). I'll implement it to spec and add tests. I'll get a PR up for this as soon as I'm assigned.

[grantfox-oss]

🦊 GrantFox — @GBOYEE has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #80)
2. Your PR will be reviewed by the AnchorNet-Org maintainers

Good luck! Track your progress on GrantFox.