security: prevent response-driven cookie persistence across egress requests

[seonghobae]

Buyer-visible ambient credential-state candidate

Fresh protected main is 10d0c51daf2ad278d66f43be479df8cf6b08ba6d. A duplicate-work precheck found no open EgressWeave issue or PR covering cookie persistence, Set-Cookie, or cross-request cookie state.

The protected-main synchronous and asynchronous builders return ordinary httpx.Client / httpx.AsyncClient instances with custom pinned transports, follow_redirects=False, and trust_env=False, but they do not define a cookie-persistence policy. HTTPX documents cookie persistence across requests as a built-in Client feature. EgressWeave also returns response headers to the HTTPX client layer after its bounded response checks, so Set-Cookie is not currently removed at the transport boundary.

This is a candidate gap until the required RED reproduction is executed on the exact accepted transport tree. Do not promote documentation behavior to a proven EgressWeave defect without that reproduction.

The risk under review is intentionally narrow: a response from the same pinned authority may cause the reused returned client to add cookie state to a later request without the caller explicitly supplying that cookie on the later request. EgressWeave's transport already rejects request-authority drift, so this issue does not claim that one returned client can replay a cookie to a different (hostname, port) authority. The product question is whether any response-controlled ambient credential/session state belongs in EgressWeave's default single-authority client at all, given the documented host-owned credential and business-authorization boundary.

Protected-main evidence:

• src/egressweave/sync_transport.py blob ce6bc1eb9fe9d89cf5783f35d8f42a4fec1e8953 constructs normal and deny-all httpx.Client instances without an explicit cookie-state policy;
• src/egressweave/transport.py blob 0a5df55e2a1793eacb7932effca2e80745de34d2 does the same for httpx.AsyncClient;
• src/egressweave/response_safety.py blob 6c1c785975eaa14477e7e1536751c44bdf88d499 treats repeated Set-Cookie as ordinary bounded response fields and does not strip them;
• official HTTPX Client documentation states that Client instances provide cookie persistence across requests.

Dependency / writer discipline

Do not open a competing implementation while current transport/request/response stacks own src/egressweave/sync_transport.py, src/egressweave/transport.py, request safety, or response safety (including current PRs #75, #78, #85, #100, #101 and their accepted successors). After the exact accepted predecessor stabilizes, reconstruct this unique ambient-cookie delta on that tree. No predecessor check, review, approval, scanner, or coverage evidence transfers.

Mandatory RCA before design selection

Distinguish these behaviors with executable evidence:

1. host code intentionally supplies a Cookie header for one request;
2. host code intentionally manages explicit cookie/session state as business credential state;
3. a pinned upstream response supplies Set-Cookie, after which the same returned EgressWeave client replays derived cookie state on a later request to that same validated authority.

Also prove the existing authority invariant independently: a request to a different (hostname, port) remains rejected even if cookie-domain semantics would otherwise allow that cookie. This is a negative control, not the claimed defect.

The default product decision should be made only after the RED evidence exists. Candidate remedies include (a) default stateless response-cookie behavior, (b) explicit rejection/stripping of response cookie mutation at the client boundary, or (c) a separately reviewed opt-in cookie/session contract. Reject any remedy that merely masks cookie values in logs while preserving unintended replay.

Acceptance criteria

• Start from the exact accepted transport predecessor and add immutable RED evidence before production changes.
• Prove or falsify, for both sync and async public builders, whether a response-provided cookie is replayed on a later request to the same exact validated authority without the caller supplying that cookie on the later request.
• Add a negative-control test proving a different (hostname, port) remains blocked by the existing pinned-authority transport regardless of cookie-domain metadata.
• If RED confirms ambient replay, select the smallest compatibility-safe root-cause remedy and document why materially distinct alternatives were rejected.
• If default stateless behavior is selected, prove repeated requests on one client cannot acquire future outbound cookie metadata solely from earlier responses; sync and async behavior must match.
• Preserve explicit caller-owned request credentials only if consistent with the accepted host-owned credential boundary; do not invent a credential store inside EgressWeave.
• If explicit cookie/session support is retained or added, require a separately reviewed opt-in contract defining single-authority scope, host/tenant ownership, lifecycle/cleanup, disclosure, and persistence semantics rather than inheriting undocumented ambient defaults.
• Preserve exact (hostname, port) authorization, DNS-rebinding resistance, TLS identity binding, no redirects/proxies/Unix sockets, request/response limits, timeout/pool policy, generic denials, deterministic stream cleanup, and public builder return shapes where feasible.
• Add beginner-readable public documentation for the accepted cookie-state ownership decision.
• Update PRD/TRD/Architecture/UML/Threat Model/traceability and [Unreleased] only where materially affected; ACTIVE-PR behavior remains unshipped.
• Maintain exact 100% owned production statement/branch coverage and complete public docstrings, with realistic sync/async integration tests.
• Verify Python 3.10–3.14 on the accepted integrated tree, package acceptance, Ruff, product guard, compileall, wheel/sdist, and installed-wheel smoke.
• Pass exact-current-head SAST and the corrected organization Security Scan whose actual pinned Dependency review action executes, current automated review with zero valid findings, every live repository/ruleset requirement, protected merge, and protected-main operational acceptance before closure.

Security/privacy rationale

Cookies commonly carry session identifiers or personalization/authentication state. The question is not whether EgressWeave may return Set-Cookie to its caller; it is whether the generic HTTPX Client layer should silently transform response-controlled metadata into later outbound request metadata inside a security library whose credential/business-authorization state is otherwise host-owned. Same-authority ambient state can still change request semantics, tenant/session behavior, and reproducibility even though cross-authority network egress remains correctly pinned.

Primary references (APA 7th)

Encode OSS Ltd. (n.d.). Clients. HTTPX. Retrieved August 10, 2026, from https://www.python-httpx.org/advanced/clients/

Encode OSS Ltd. (n.d.). Requests compatibility: Cookies. HTTPX. Retrieved August 10, 2026, from https://www.python-httpx.org/compatibility/

Non-goals

• No claim that the existing client can send a request to a different validated authority; pinned authority enforcement remains a separate invariant.
• No browser cookie implementation.
• No EgressWeave-owned durable credential/session database.
• No blanket removal of caller-supplied business credentials without a reviewed compatibility decision.
• No local workaround for the separately governed central dependency-review defect.
• No competing edits to transport branches currently under active ownership.