[bidexbusuyi-eng]

Summary

Harden backend auth: scoped rate limiting, trusted proxies, and API key scopes/expiry

What was solved

#971 — Rate-limit by authenticated merchant identity

Implement merchant-scoped rate limiting in the backend keyed on verified authentication credentials (from the auth extractor) instead of caller-controlled headers, while keeping anonymous traffic bounded by a separate fallback limit. Add tests proving identities cannot be spoofed via headers to bypass limits and that anonymous requests remain rate-limited.

Addressed:

• Changed: backend/src/auth.rs, backend/src/extractors.rs
• Derive the rate-limit key from verified credentials (authenticated merchant identity from auth.rs/extractors.rs), not from caller-supplied headers such as X-Merchant-Id or X-Forwarded-For.
• Apply per-merchant limits for authenticated requests and a separate bounded limit for anonymous/unauthenticated traffic.
• Ensure spoofed identity headers cannot change or bypass the effective rate-limit bucket for an authenticated caller.

#972 — Make trusted-proxy handling explicit

Make trusted-proxy handling explicit in the backend so that X-Forwarded-For is only honored for client-IP and rate-limit decisions when the immediate peer is a configured trusted proxy; otherwise forwarded headers are ignored. Add configuration for trusted proxy addresses and tests covering trusted vs. untrusted proxy behavior.

Addressed:

• Changed: backend/src/extractors.rs, backend/src/lib.rs, backend/.env.example
• Introduce explicit configuration of trusted proxy addresses (e.g., env var / config field) consumed by the backend.
• Only accept X-Forwarded-For for client IP and rate-limit decisions when the request originates from a configured trusted proxy.
• Ignore forwarded headers from untrusted peers, falling back to the direct connection IP.

#973 — Add scopes to merchant API keys

Add least-privilege scopes to merchant API keys so keys can be restricted to read, write, and webhook operations. Key creation must accept scopes, and authorization must enforce them with tests covering allowed and denied routes.

Addressed:

• Changed: backend/src/auth.rs, backend/src/extractors.rs, backend/src/handlers.rs
• API key creation accepts a set of scopes (read, write, webhook) and persists them with the key
• Authorization checks enforce scopes per route, denying requests whose key lacks the required scope
• Add authorization tests covering both allowed and denied routes for each scope

#974 — Add API-key expiry and last-used metadata

Add API-key expiry and last-used metadata to the backend auth layer, with an operator-configurable rotation policy. Expired keys must be rejected during authentication, and non-secret metadata (expiry, last-used timestamp, rotation policy) must be exposed without leaking the key secret.

Addressed:

• Changed: backend/src/auth.rs, backend/src/extractors.rs
• Track an expiration timestamp per API key and reject expired keys during authentication
• Record and expose last-used metadata for each API key
• Support an operator-configurable rotation policy (e.g. max key age / rotation window) via configuration

Changes

• backend/src/auth.rs (modify)
• backend/.env.example (modify)
• backend/src/extractors.rs (modify)
• backend/src/handlers.rs (modify)
• backend/src/lib.rs (modify)

Approach

1. Rate-limit by authenticated merchant identity #971 — Rate-limit by authenticated merchant identity (Changed: backend/src/auth.rs, backend/src/extractors.rs)
2. Make trusted-proxy handling explicit #972 — Make trusted-proxy handling explicit (Changed: backend/src/extractors.rs, backend/src/lib.rs, backend/.env.example)
3. Add scopes to merchant API keys #973 — Add scopes to merchant API keys (Changed: backend/src/auth.rs, backend/src/extractors.rs, backend/src/handlers.rs)
4. Add API-key expiry and last-used metadata #974 — Add API-key expiry and last-used metadata (Changed: backend/src/auth.rs, backend/src/extractors.rs)

Issues

Closes #971
Closes #972
Closes #973
Closes #974

[drips-wave]

@bidexbusuyi-eng 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