Closed Bug 1477696 Opened 4 years ago Closed 3 years ago

webExtension: webRequest.onHeadersReceived: accidentally overwriting header from other extensions


(WebExtensions :: Request Handling, defect, P2)

61 Branch


(Not tracked)



(Reporter: bugzilla, Unassigned)




(3 files)

772 bytes, application/zip
772 bytes, application/zip
514 bytes, application/zip
Attached file
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180705213349

Steps to reproduce:

When two webExtensions modify the headers for a request it is possible that an extension overwrites changes that another extension made by accident.
This is a major problem when adding Content-Security-Policy headers.

Real work problem:

Reproduction scenario:
1. install the three provided extension temporarily
2. open any web page
-> in the browser console you see the headers provided by the two extensions csp-ext1 and csp-ext2 -> the second extension does not see the modifications made by the first one
-> you also see the actual headers -> the CSP and "X-Powered-By" header are only taken from the second extension despite the effort that is made to just append the values.

Actual results:

The extension that is called the second time can accidentally overwrite the modifications of the first extension as it does not see the modifications done by the first one.

Expected results:

The second extension should see the modifications from the first extension to respect the changes.
Attached file
Attached file
See Bug 1417249
Flags: needinfo?(mixedpuppy)
Priority: -- → P2
tl;dr I need to think about this more, notes below.

CSP specifically allows for multiple headers[1].  Documentation states extensions can see one-anothers modifications[2] which is no longer true (it was at one point).  It is easy to reproduce the problem with a single extension (I've modified the contributed extensions into one, will attach).  By our current design, the WebRequest api makes all the api calls into extensions prior to applying any changes, thus one handler will not see changes made by another handler.  We also cache the headers and make a copy of that cache for each call to an extension listener.  This is a fairly large change in behavior from Chrome (assuming Chrome works as documented), but changing it would probably cause performance issues.

I think the primary problem is that headers that can have more than one, such as CSP, do not work that way.  Secondary is that an extension cannot examine CSP set by another extension in order to potentially adjust CSP.  A potentially larger issue is that we may be stepping on headers in some unintentional way, which I need to look at more.

Flags: needinfo?(mixedpuppy)
See also:

Headers will not be merged if not present in original response.

Any news here?

The main issue with the CSP headers is solved with So for me this bug can be closed.

Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.