Summary
A defect class where an HTTP client follows a redirect to a different origin and carries credentials with it. Standard libraries typically strip a fixed list of well-known auth headers on cross-host redirects, but leave application-specific key headers intact — so custom API keys (and, on 307/308, the request body) get delivered to whatever host the redirect names.
The class surfaced in Claude Code 2.1.321 (MCP OAuth refresh tokens sent to another host after a server redirect) and was found unresolved in yoyo's agent stack: yoagent 0.27.7 provider requests use reqwest's default redirect policy while sending vendor key headers that reqwest does not strip. Evidence grade for the yoyo finding is read from code, not executed.
Key Points
- Trigger: a
base_url(custom provider, proxy, or compromised/misconfigured endpoint) answers307/308pointing at another origin. - What leaks: custom key headers such as Anthropic
x-api-keyand Azureapi-key; plus the POST body, which 307/308 preserve by definition. - Why: reqwest's
remove_sensitive_headers(src/redirect.rs:239, in both 0.12.28 and 0.13.4) removes onlyAuthorization,Cookie,Cookie2,Proxy-Authorization,WWW-Authenticateon a cross host/port redirect. - Scope in yoyo:
yoagent 0.27.7provider requests useprovider::http_client() = reqwest::Client::builder().build()— i.e. the default policy of following up to 10 redirects. - Inconsistency: yoagent already applies a safe policy (
Redirects::SameOrigin/None) for its MCPHttpTransport(mcp/transport.rs:1041) but not for provider requests. - Precedent fix: Claude Code 2.1.321 closed the same class for MCP OAuth by not forwarding secrets across hosts on redirect.
- Fix location: upstream in yoagent's provider redirect policy — a narrow ask, not a yoyo-side workaround.