502 body leaks the internal backend host and port to the client #37

New issue

Open

opened 2026-10-20 14:02:52 +00:00 by james.oates · 0 comments

james.oates commented

2026-10-20 14:02:52 +00:00

Owner

proxy.rs:816-822 serves the raw upstream error to the client:

tracing::error!("Proxy error: {}", e);
return Ok((
    StatusCode::BAD_GATEWAY,
    format!("Failed to reach service: {}", e),
)
    .into_response());

A reqwest connect error's Display includes the target URL, so an external
caller receiving a 502 learns the internal backend's scheme, host and port.

Log it (already done on the line above), serve a generic message.

Low severity — it discloses topology, not credentials — but it is live in v1.1.0
and reachable by anyone who can make a request to a service whose backend is
down.

The same site is one of four ER-generated errors that bypass error_response
entirely (proxy.rs:463 501, proxy.rs:642 413, proxy.rs:816 502,
proxy.rs:823 504), so they get no content negotiation and no
X-Edge-Router-Fallback header either. Routing them through error_response
fixes this leak as a side effect — see
specs/2026-10-20-runtime-resilience-and-error-attribution-design.md, Part 2.

`proxy.rs:816-822` serves the raw upstream error to the client: ```rust tracing::error!("Proxy error: {}", e); return Ok(( StatusCode::BAD_GATEWAY, format!("Failed to reach service: {}", e), ) .into_response()); ``` A `reqwest` connect error's `Display` includes the target URL, so an external caller receiving a 502 learns the internal backend's scheme, host and port. Log it (already done on the line above), serve a generic message. Low severity — it discloses topology, not credentials — but it is live in v1.1.0 and reachable by anyone who can make a request to a service whose backend is down. The same site is one of four ER-generated errors that bypass `error_response` entirely (`proxy.rs:463` 501, `proxy.rs:642` 413, `proxy.rs:816` 502, `proxy.rs:823` 504), so they get no content negotiation and no `X-Edge-Router-Fallback` header either. Routing them through `error_response` fixes this leak as a side effect — see `specs/2026-10-20-runtime-resilience-and-error-attribution-design.md`, Part 2.

james.oates referenced this issue

2026-10-20 15:03:23 +00:00

Runtime resilience: survive OpenBao being unavailable #40

james.oates referenced this issue

2026-10-26 17:53:55 +00:00

The WebSocket path has no connect timeout, no idle timeout and no connection cap #62