cmd/go: do not forward GOAUTH-derived credential headers across cross-host redirects

[1seal]

summary:

• when cmd/go uses GOAUTH, it may add arbitrary custom headers (not just Authorization) to authenticate to a specific https:// URL prefix.
• net/http copies request headers across redirect hops, and cmd/go currently preserves those copied headers.
• if a request authenticates to host a and then redirects to a different host b, those GOAUTH-derived headers can be forwarded to b.

expected behavior:

• when following a redirect to a different host, cmd/go should not forward GOAUTH-derived credential headers from the original host.
• credentials should only be applied when they are derived for (or match) the destination URL prefix.

actual behavior:

• after GOAUTH is applied (triggered by a prior 4xx), a subsequent 3xx redirect to a different host can result in the GOAUTH-derived header being sent to the redirect target host.

notes:

• i understand from the private security triage discussion that this is not considered a security vulnerability. i am filing this as a behavior change / hardening request for cmd/go’s GOAUTH scoping model.
• redirect preconditions are: unauthenticated 4xx (to trigger GOAUTH), then authenticated 3xx (redirect), then a redirect target on a different host.

repro sketch:

1. configure GOAUTH to return a custom header for https://a.test/ (example: X-Goauth-Token: secret).
2. make a request to https://a.test/ such that:
   • the first response is 401,
   • the second request includes the GOAUTH header,
   • the second response is a 302 redirect to https://b.test/.
3. observe that the request to https://b.test/ contains X-Goauth-Token.

proposed fix:

• in cmd/go’s redirect handler, clear the copied header set on redirected requests and re-derive credentials based on the destination URL only.
• add a regression test that proves a custom GOAUTH header is applied to a.test but not forwarded to b.test.

callsite (observed):

• a3688ab
• src/cmd/go/internal/web/http.go (redirect policy)

patch + test:

• tracking issue: cmd/go: do not forward GOAUTH-derived credential headers across cross-host redirects #77839
• patch + regression test: prepared locally; not posted inline because golang/go prefers code submission via cla/gerrit.
• regression test name: TestGOAUTHRedirectDoesNotForwardCustomHeaders (package cmd/go/internal/web)

[1seal]

follow-up (edited): patch removed per contributor process

per maintainer guidance, i removed the inline patch from this issue comment (code submission via cla/gerrit).

see the later comment for the test name and the minimal behavior change proposal.

[1seal]

follow-up (edited): patch removed per contributor process

i removed the inline diff from this issue comment per maintainer guidance (code submission via cla/gerrit).

i still believe the minimal change is: on cross-host redirects, clear the copied header set and re-derive goauth credentials for the destination url only, with a regression test covering a custom header (x-goauth-token).

i can submit the change through the normal process once cla is in place.

test idea:

• go test cmd/go/internal/web -run TestGOAUTHRedirectDoesNotForwardCustomHeaders

[seankhliao]

please do not post patches in the issue tracker, code submission needs to go through CLA.

[gabyhelp]

Related Issues

• cmd/go: GOAUTH command output can't have a trailing slash #71889 (closed)
• cmd/go: GOAUTH credential leak [CVE-2024-45340] #71249 (closed)
• net/http: sensitive headers incorrectly sent after cross-domain redirect [CVE-2024-45336] #70530 (closed)
• net/http: sensitive headers not cleared on cross-origin redirect CVE-2025-4673 #73816 (closed)
• net/http, net/http/cookiejar: incorrect forwarding of sensitive headers and cookies on HTTP redirect [CVE-2023-45289] #65065 (closed)

Related Code Changes

• cmd/go: add GOAUTH mechanism for HTTP authentication
• cmd/go: add HTTP authentication mechanism via GOAUTH

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

cc @golang/command-line @golang/security

[dmitshur]

From triage, it sounds like the redirect happens by an initially trusted source, and not forwarding GOAUTH may cause it to not work for the target. So there may not be any behavior change to do here.