X-RateLimit-* response headers are misleading for Bearer/API-key clients #82

New Issue

2026-09-01T00:07:14-04:00

jared commented

2026-09-01 00:07:14 -04:00

Severity: Low

RateLimitMiddleware::getStatus() (called by addHeaders()) only reports the session-based counter's limit/remaining/reset — never the IP-based bucket that actually governs Bearer traffic (see the related "one key can starve another" issue). A Bearer client reading these headers to self-throttle sees an essentially-always-fresh session bucket (since a new session starts each request per the related finding) and has no visibility into how close it actually is to the real, IP-based 429 threshold.

Fix: Once/if Bearer traffic is rate-limited by API key (see related issue), report that bucket's status in these headers for Bearer-authenticated requests instead of the meaningless session counter.

**Severity:** Low `RateLimitMiddleware::getStatus()` (called by `addHeaders()`) only reports the **session**-based counter's limit/remaining/reset — never the IP-based bucket that actually governs Bearer traffic (see the related "one key can starve another" issue). A Bearer client reading these headers to self-throttle sees an essentially-always-fresh session bucket (since a new session starts each request per the related finding) and has no visibility into how close it actually is to the real, IP-based 429 threshold. **Fix:** Once/if Bearer traffic is rate-limited by API key (see related issue), report that bucket's status in these headers for Bearer-authenticated requests instead of the meaningless session counter.

jared added the priority/low rate-limiting labels 2026-09-08 10:15:48 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/tinker_tickets#82