Fix #280: rate limiter keys buckets on peer address, not client-controlled X-Forwarded-For #284

Merged
fen merged 1 commits from fix-280 into dev 2026-09-18 01:33:04 +00:00
1 Commits
Author SHA1 Message Date
fen f63efc6d88 Fix rate limiter bypass via client-controlled X-Forwarded-For (#280)
CI / docker (pull_request) Skipped
CI / test (pull_request) Successful in 25s
clientIP() keyed rate-limit buckets on the rightmost X-Forwarded-For
entry, assuming traefik appends the real client IP. The deployed ingress
does not rewrite XFF, so rotating the header gave a fresh bucket per
request (pentest H1: 8 creates with rotating XFF -> 6x201).

Now the bucket keys on the actual peer address (RemoteAddr) by default;
every client-supplied IP header is ignored. Deployments whose ingress
overwrites a client-IP header can opt in via PALETTE_TRUSTED_IP_HEADER
(e.g. CF-Connecting-IP behind Cloudflare) to restore per-client limits.

Adds tests: rotating XFF no longer resets the bucket; the trusted header
is honored only when explicitly configured.
2026-09-17 20:29:40 -05:00