Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: Authorization header stripping in client on redirects incorrect when redirecting from http to https #35104

h3kker opened this issue Oct 23, 2019 · 4 comments


Copy link

@h3kker h3kker commented Oct 23, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.4 darwin/amd64

Does this issue reproduce with the latest release?

Should (source code at indicates that)

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dh/6nzg_lhs19l_kxwv21s_8wz80000gn/T/go-build031339938=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

A go cli application (singularity, tries to make a http request with a Authorization: Bearer .. header.

What did you expect to see?

The request on the server with a Authorization: Bearer ... header

What did you see instead?

Header was stripped from the request. Trying to do the same request with the same headers with curl leaves the header intact.

I think the problem in this case is that

As far as I can see there is a problem in isDomainOrSubdomain. It does an equality or suffix match on the original + redirected hostnames. But the hostnames come from canonicalAddr, which appends the port from the protocol. So it would check whether is a suffix of, which it isn't, and then strip the header.

It seems a bit strange, in this case it would kick in a security check for something that actually improves security ;-) It is either a bug in the code or in the documentation, which does not mention protocol or ports.

@dmitshur dmitshur changed the title Authorization header stripping in src/net/http/client on redirects incorrect when redirecting from http to https net/http: Authorization header stripping in client on redirects incorrect when redirecting from http to https Oct 23, 2019
Copy link

@dmitshur dmitshur commented Oct 23, 2019

Thanks for the report.

/cc @bradfitz

Copy link

@neild neild commented Oct 17, 2020

From my reading, libcurl's behavior is to keep sensitive headers only when the hostname is an exact match (ignoring the port).

I think that if we're going to preserve a header on a redirect from to, then there's no reason not to preserve it on a redirect from one port to another on the same host. (Perhaps we should refuse to copy headers on a security downgrade from https to http?)

Copy link

@manigandand manigandand commented Aug 26, 2021

If the sensitive headers can be copied for subdomains then why not for the same host without a port.

I expect the headers to be copied to the same host of the different ports.

Redirecting from to I expect the sensitive headers also should be sent.
Currently, this is not happening because we are checking for exact host matches from the different canonical host addresses.

func isDomainOrSubdomain(sub, parent string) bool {
	if sub == parent {
		return true
	// If sub is "" and parent is "",
	// that means sub must end in "."+parent.
	// Do it without allocating.
	if !strings.HasSuffix(sub, parent) {
		return false
	return sub[len(sub)-len(parent)-1] == '.'

Copy link

@asutosh97 asutosh97 commented Aug 26, 2021

Yes, agree with what @manigandand said
Maybe we should just simply check the hostnames and leave out the ports when doing the check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants