Summary

Describe the problem and fix in 2–5 bullets:

• Problem: fetchWithSsrFGuard reused request headers across manual redirects, including cross-origin hops.
• Why it matters: sensitive headers (Authorization, Cookie) could be forwarded to a different origin.
• What changed: on redirect, when origin changes, sensitive headers are stripped before the next request; same-origin redirects keep headers.
• What did NOT change (scope boundary): SSRF host/IP policy logic, redirect limits, method/body behavior, and non-sensitive header forwarding were not changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes # (none)
• Related # (none)

User-visible / Behavior Changes

• Cross-origin redirects no longer forward Authorization/Cookie set on the initial request.
• Same-origin redirect behavior is unchanged.
• No config/default changes.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (Yes)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:
  • This reduces credential leakage risk on cross-origin redirects by stripping sensitive headers before the follow-up request.

Repro + Verification

Environment

• OS: macOS (local dev machine)
• Runtime/container: Node 22+, pnpm test runner
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): default test config

Steps

1. Run pnpm test src/infra/net/fetch-guard.ssrf.test.ts on the pre-fix code.
2. Observe failure in strips sensitive headers when redirect crosses origins (authorization was still present on second request).
3. Apply fix and rerun pnpm test src/infra/net/fetch-guard.ssrf.test.ts src/media/input-files.fetch-guard.test.ts.

Expected

• Cross-origin redirect follow-up request does not include Authorization/Cookie.
• Same-origin redirect still keeps headers.

Actual

• Before fix: Authorization leaked to redirected cross-origin request.
• After fix: sensitive headers stripped only for cross-origin redirects; all targeted tests pass.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • Added/ran regression test for cross-origin redirect header stripping.
  • Added/ran control test for same-origin redirect header retention.
• Edge cases checked:
  • Existing SSRF guard tests still pass.
  • Adjacent consumer test (src/media/input-files.fetch-guard.test.ts) still passes.
• What you did not verify:
  • Full live network E2E across external providers/channels.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:
  • N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert commit fbd5511f0.
• Files/config to restore:
  • src/infra/net/fetch-guard.ts
  • src/infra/net/fetch-guard.ssrf.test.ts
• Known bad symptoms reviewers should watch for:
  • Unexpected 401/403 only after cross-origin redirects where upstream expected forwarded auth headers.

Risks and Mitigations

• Risk: some integrations may have relied on forwarding auth headers across origins.
• Mitigation: only sensitive headers are stripped, only on origin change, and same-origin behavior is preserved.
• Risk: custom sensitive headers (non-standard names) are still forwarded.
• Mitigation: kept scope minimal to avoid breaking existing flows; follow-up can extend protected header list if needed.

Greptile Summary

This PR hardens fetchWithSsrFGuard by stripping sensitive headers (Authorization, Proxy-Authorization, Cookie, Cookie2) when a manual redirect crosses origins, aligning with browser credential-stripping behavior and preventing credential leakage to unintended hosts.

• Adds a CROSS_ORIGIN_REDIRECT_SENSITIVE_HEADERS constant and stripSensitiveHeadersForCrossOriginRedirect helper in src/infra/net/fetch-guard.ts
• Introduces a currentInit variable to track evolving request options across redirect hops without mutating the caller's original params.init
• Compares nextParsedUrl.origin against parsedUrl.origin on each redirect to determine if headers should be stripped
• Adds two regression tests covering cross-origin header stripping and same-origin header retention
• No issues found: the implementation is clean, correctly handles edge cases (multiple hops, relative URLs, case-insensitive header deletion), and does not mutate caller state

Confidence Score: 5/5

• This PR is safe to merge — it's a targeted, well-tested security hardening with no behavioral changes to same-origin flows.
• The change is minimal and focused: it adds a single conditional check in the existing redirect loop to strip sensitive headers on cross-origin hops. The implementation correctly uses the URL origin comparison, the Headers API's case-insensitive delete, and avoids mutating the caller's original init object. Both positive and negative test cases are included. No existing behavior is altered for same-origin redirects. The approach mirrors standard browser credential-stripping behavior (Fetch spec).
• No files require special attention.

_{Last reviewed commit: fbd5511}

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}