All four were real bypass or fail-open paths on an endpoint about to be
publicly exposed:
- X-Forwarded-For was trusted from ANY peer. The origin also listens on the
tailnet, so anyone reaching it directly could pick -- and rotate -- their
own rate-limit key by sending a header. Now honored only when the socket
peer is in a configured trusted_proxies list, and the last hop must parse
as a real IP. trust_forwarded_for without trusted_proxies REFUSES startup.
- Capacity eviction was fail-open and exploitable: an attacker able to mint
many distinct keys could evict their own live window and start fresh. Now
reclaims only EXPIRED windows and refuses the new key when all are live.
Fail closed -- /v1/link is invite-only, so hitting the cap is an attack.
- The clock was read outside the lock, so racing threads could append out of
order; both retry_after (hits[0]) and reclamation (v[-1]) assume the list
is chronological. Moved inside.
- Config types were unvalidated: `"enabled": null` or `0` silently disabled
limiting, and the string "false" enabled XFF trust (non-empty strings are
truthy). Booleans must now be real JSON booleans; rate_limit must be an
object.
Codex confirmed no path-variant bypass (dispatch is exact-match) and no
keep-alive/pipelining bypass (rejects set close_connection).
Tests 87 -> 99: capacity fail-closed with the victim's window proven
untouched through a 40-key flood, 200-thread chronological-order check,
untrusted-peer spoof, junk XFF, and every config-type trap.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LTARYHX7GPepi3CH3tp5pg
