Closed Bug 1816115 Opened 10 months ago Closed 5 months ago

Netmonitor shows http header "proxy-authentication" that isn't actually sent to the receiving server


(DevTools :: Netmonitor, defect, P3)

Firefox 110


(firefox116 fixed)

116 Branch
Tracking Status
firefox116 --- fixed


(Reporter:, Assigned: bomsy, NeedInfo)


(Whiteboard: [necko-triaged][necko-priority-review])


(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

In Network settings, add a http proxy with username and password.

Actual results:

In the proxy, for the request of CONNECT method, it sends 407 to firefox to challenge basic authenticate, then firefox sends http header proxy-authentication to proxy, after it is validated successfully, the proxy connects the 2 sockets (the one to firefox and the one to the target host) as a channel. The problem is that for the following http requests via this channel, firefox still sends http header proxy-authentication, which exposes the secret username/password to the remote host.

Expected results:

The following http requests via the channel created by CONNECT should not send http header proxy-authentication for security, just like what Safari or Chrome does.

Group: firefox-core-security → network-core-security
Component: Untriaged → Networking: HTTP
Product: Firefox → Core

It's not clear this is wrong. Traditionally proxy auth worked like regularly http auth: you had to send the header with each request or the proxy would send you another 407 (HTTP is famously a "stateless protocol"). If you didn't send the header the first time then every request had to be made twice as you replied to all the 407s. The HTTP spec (rfc9110) says the proxy that requested the auth is supposed to "consume" the header and not send it along.

But maybe more modern versions of HTTP (e.g. HTTP/2 or /3) no longer require that?

Flags: needinfo?(valentin.gosu)

I agree that browser should send proxy authentication header the first time for CONNECT if it is challenged by code 407.

Section 9.3.6 of rfc9110 says "Proxy authentication might be used to establish the authority to create a tunnel". My understanding is that Proxy authentication is used in CONNECT to create the tunnel. Once the tunnel is established, all the following requests via the tunnel are directly sent to the target host, which should not bring proxy authentication header. e.g. It is valid that browser sends https requests to target host (SSL handshake is between browser and target host) via the tunnel established by a http proxy. In this case, the proxy have not way to listen the https payloads so it cannot stripe proxy authentication header from the requests. Thus proxy authentication will be sent to the target host unexpectedly.

Actually I mean Proxy-Authorization instead of proxy authentication.

Proxy-Authorization: basic aGVsbG86d29ybGQ=

I think the reporter's assessment is correct.
We shouldn't set a Proxy-Authorization header on HTTP(S) requests going through a HTTPS tunnel, or HTTPS requests going through an HTTP tunnel - even for HTTP/1.1. HTTP requests through an HTTP proxy should keep sending the Proxy-Authorization, because the proxy is possibly stateless. Given H2 and H3 are always encrypted, I think we shouldn't send the Proxy-Authorization for any non-CONNECT requests going to a H2 or H3 proxy.

Severity: -- → S3
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
Priority: -- → P1
Whiteboard: [necko-triaged][necko-priority-review]

Hi Reporter,

Could you share how did you observe this issue?
According to the code here, Firefox does prune Proxy-Authorization for the requests that will go through a tunnel.


Flags: needinfo?(
  1. In network settings, add a http proxy with username/password.
  2. Browse a website via the http proxy.
  3. Right-click on the web page, and choose Inspect.
  4. Click Network on the tab, choose any GET or POST request on the left side, then check the headers on the right side, you will see Proxy-Authorization Basic XXXXX in the request headers.
Flags: needinfo?(

If I use mitmproxy --proxyauth="user:pass" then navigate to I don't see the proxy-authorization being reflected back.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

If I use mitmproxy --proxyauth="user:pass" then navigate to I don't see the proxy-authorization being reflected back.

Right, I think we don't send Proxy-Authorization to the server when CONNECT is used.
I think this is a devtool issue.

I'll let devtool people decide whether to show Proxy-Authorization.

Group: network-core-security → firefox-core-security
Component: Networking: HTTP → Netmonitor
Product: Core → DevTools

I am using this simple proxy written in GoLang,

package main

import (

var portNumber = flag.String("port", "12345", "port number")

func main() {
proxy := goproxy.NewProxyHttpServer()
proxy.Verbose = false

log.Println("auth basic")

log.Println("listen:" + *portNumber)
log.Fatal(http.ListenAndServe(":" + *portNumber, proxy))


It is surprising that the headers are different between and devtool's request headers:

"headers": {
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8",
"Accept-Encoding": "gzip",
"Accept-Language": "en-US,en;q=0.5",
"Host": "",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0",
"X-Amzn-Trace-Id": "Root=1-63eb93af-44c768f60442df520250513e"


GET /headers HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Authorization: Basic XXXXXXXXXXX
Connection: keep-alive
Upgrade-Insecure-Requests: 1

That's because the Proxy-Authorization header is set on the channel, but isn't actually sent to the server.
This line here strips the proxy headers before sending them out the the server.

Valentin, am I right in thinking we can remove the security flag here?

Severity: S3 → --
Flags: needinfo?(valentin.gosu)
Priority: P1 → --
Summary: redundant http header "proxy-authentication" - security issue → Netmonitor shows http header "proxy-authentication" that isn't actually sent to the receiving server

Yes, I think we can remove the security flag.

Flags: needinfo?(valentin.gosu)
Group: firefox-core-security
Severity: -- → S3
Priority: -- → P3
Flags: needinfo?(hmanilla)

If the Proxy-Authorization is not sent to the server (for non CONNECT), we could

  • Strip it out and not show it in devtools or
  • Show it but some sort of visual indicator (grayed out) in devtools indicating that the request header is not actually sent.

Any thoughts?

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

If I use mitmproxy --proxyauth="user:pass" then navigate to I don't see the proxy-authorization being reflected back.

When i switched to the headers tab on i can see the Proxy-Authorization on the list of request headers, but its not part of the JSON or Raw Data. I guess there is slight difference??

I noticed the Proxy-Authorization is also shown in the chrome devtools?

Flags: needinfo?(valentin.gosu)
Flags: needinfo?(hmanilla)
Flags: needinfo?(

I think not showing it in devtools is the right choice - the header is not being sent to the server
We can also probably improve the proxy visibility story with bug 1707192 and related bugs.

Flags: needinfo?(valentin.gosu)
Assignee: nobody → hmanilla
Attachment #9338606 - Attachment description: WIP: Bug 1816115 - [devtools] Stop showing the Proxy-Authorization header → Bug 1816115 - [devtools] Stop showing the Proxy-Authorization header r=#devtools-reviewers
Pushed by
[devtools] Stop showing the Proxy-Authorization header r=devtools-reviewers,nchevobbe
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
You need to log in before you can comment on or make changes to this bug.