clientIP takes the rightmost XFF entry, which is correct: spoofed X-Forwarded-For / X-Real-Ip / True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429). Remaining inherent limitation: offices/VPNs behind one IP share the burst-5/1rps create budget, so one heavy user can 429 everyone. Filing to document the verified anti-spoofing behavior and the shared-bucket tradeoff.
Repro
1. Six rapid POSTs to /api/pastes from one IP: 201 x5 then 429.
2. Repeat while sending 'X-Forwarded-For: 1.2.3.4', 'X-Real-Ip: 9.9.9.9', 'True-Client-Ip: 3.3.3.3': all still 429 (no bypass).
Found during exploratory security/bug pass on palette-dev (2026-09-09). Reporting only, no fix attached.
clientIP takes the rightmost XFF entry, which is correct: spoofed X-Forwarded-For / X-Real-Ip / True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429). Remaining inherent limitation: offices/VPNs behind one IP share the burst-5/1rps create budget, so one heavy user can 429 everyone. Filing to document the verified anti-spoofing behavior and the shared-bucket tradeoff.
### Repro
```
1. Six rapid POSTs to /api/pastes from one IP: 201 x5 then 429.
2. Repeat while sending 'X-Forwarded-For: 1.2.3.4', 'X-Real-Ip: 9.9.9.9', 'True-Client-Ip: 3.3.3.3': all still 429 (no bypass).
```
Found during exploratory security/bug pass on palette-dev (2026-09-09). Reporting only, no fix attached.
fen
added spent time 5 seconds2026-09-10 03:49:08 +00:00
fen
added the Low label 2026-09-10 03:49:49 +00:00
Fix proposal: key the rate limiter on a client-supplied identity where available (viewer cookie or authenticated token) with IP as fallback, so users behind shared egress IPs are not collectively throttled. Would need a small sharded per-identity counter with the same 429 semantics as #81.
Fix proposal: key the rate limiter on a client-supplied identity where available (viewer cookie or authenticated token) with IP as fallback, so users behind shared egress IPs are not collectively throttled. Would need a small sharded per-identity counter with the same 429 semantics as #81.
fen
added spent time 4 minutes2026-09-10 13:57:36 +00:00
poslop
added the Assigned label 2026-09-10 15:47:27 +00:00
That is fine to implement. Note that this will allow a potential malicious actor to spoof the client side ID for each request and DOS anyways with this method. This is a fine risk to accept I dont think that will be a major problem maybe this could be revisited in the future with another solution.
That is fine to implement. Note that this will allow a potential malicious actor to spoof the client side ID for each request and DOS anyways with this method. This is a fine risk to accept I dont think that will be a major problem maybe this could be revisited in the future with another solution.
Documentation-only resolution (no code changes). Added wiki page 'security' (security.md) documenting: (1) clientIP takes the rightmost X-Forwarded-For entry, so spoofed XFF/X-Real-Ip/True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429); (2) the burst-5 / 1rps create budget per IP; (3) the known inherent limitation that offices/VPNs sharing one egress IP share a single bucket, so one heavy user can 429 everyone. Wiki has no PR gate, so no fix branch/PR was opened; a human should confirm the doc location.
Documentation-only resolution (no code changes). Added wiki page 'security' (security.md) documenting: (1) clientIP takes the rightmost X-Forwarded-For entry, so spoofed XFF/X-Real-Ip/True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429); (2) the burst-5 / 1rps create budget per IP; (3) the known inherent limitation that offices/VPNs sharing one egress IP share a single bucket, so one heavy user can 429 everyone. Wiki has no PR gate, so no fix branch/PR was opened; a human should confirm the doc location.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
clientIP takes the rightmost XFF entry, which is correct: spoofed X-Forwarded-For / X-Real-Ip / True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429). Remaining inherent limitation: offices/VPNs behind one IP share the burst-5/1rps create budget, so one heavy user can 429 everyone. Filing to document the verified anti-spoofing behavior and the shared-bucket tradeoff.
Repro
Found during exploratory security/bug pass on palette-dev (2026-09-09). Reporting only, no fix attached.
Fix proposal: key the rate limiter on a client-supplied identity where available (viewer cookie or authenticated token) with IP as fallback, so users behind shared egress IPs are not collectively throttled. Would need a small sharded per-identity counter with the same 429 semantics as #81.
That is fine to implement. Note that this will allow a potential malicious actor to spoof the client side ID for each request and DOS anyways with this method. This is a fine risk to accept I dont think that will be a major problem maybe this could be revisited in the future with another solution.
Documentation-only resolution (no code changes). Added wiki page 'security' (security.md) documenting: (1) clientIP takes the rightmost X-Forwarded-For entry, so spoofed XFF/X-Real-Ip/True-Client-Ip cannot bypass or poison the bucket (verified - all spoof variants stayed 429); (2) the burst-5 / 1rps create budget per IP; (3) the known inherent limitation that offices/VPNs sharing one egress IP share a single bucket, so one heavy user can 429 everyone. Wiki has no PR gate, so no fix branch/PR was opened; a human should confirm the doc location.
this is fine for now