Closed Bug 1615901 Opened 1 year ago Closed 1 year ago

Origin header should not be set on OpenSearch POST


(Firefox :: Search, defect, P1)

73 Branch



Firefox 75
75.2 - Feb 24 - Mar 8
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 --- verified


(Reporter: alex_y_xu, Assigned: daleharvey)


(Regression, )


(Keywords: regression)


(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. navigate to
  2. add as a search engine
  3. set as default search engine
  4. select text, right-click, "Search DuckDuckGo Lite"

Actual results:

page displays "forbidden"

Expected results:

search results displayed

this has been reported by other users in various forums, usually resolved by switching to non-Lite. I believe this is a bug though: opensearch engines should not be sent the domain of my search origin.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

You can enter about:config into the address bar and set network.http.sendOriginHeader to 0

That seems to make the search results load. I'm not entirely sure what actually triggers the 403 forbidden response, since it worked fine at first in a brand new profile.

Has STR: --- → yes
Component: Untriaged → Search

I reproduced it in a new profile with Firefox 73.0 on Linux.

Assignee: nobody → dharvey

note that this is also an issue if you highlight the text and drag it to a new tab

Iteration: --- → 75.1 - Feb 10 - Feb 23
Points: --- → 5
Priority: -- → P1
Iteration: 75.1 - Feb 10 - Feb 23 → 75.2 - Feb 24 - Mar 8
Pushed by
Dont send Origin header with context menu searches. r=ckerschb,Standard8
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75
Flags: qe-verify+


I’ve tried to reproduce this issue in order to verify it, with different Firefox versions (73.0, Nightly from 2020-02-04, latest nightly 2020-03-20 and beta 75.0b6) on different Oses : Windows 10x64, mac0S 10.15 and Ubuntu 18.04x64. Unfortunately I couldn’t reproduce it by following the str from comment 0, the searched result was displayed properly.

Alex, could you please verify if this is fixed on latest beta? (


Flags: needinfo?(alex_y_xu)
Flags: needinfo?(alex_y_xu)
Flags: qe-verify+
Duplicate of this bug: 1624151

Considering the privacy issue, and the straightforward fix, should we consider uplifting (some form of) this to 68 esr?

Flags: needinfo?(standard8)

I think that would be reasonable. Dale, do you want to see if this can be uplifted to 68 cleanly? I suspect it should be possible.

Flags: needinfo?(standard8) → needinfo?(dharvey)

[Tracking Requested - why for this release]:

As Gijs mentions, it improves privacy, fixes search engine breakage and is relatively simple

Flags: needinfo?(dharvey)

After looking at the patch on esr68, I realised that the test passed without the patch. Dale mentioned about bug 1424076, and that landed in 70.

I checked with mozregression and got:

10:31.42 INFO: Last good revision: 62286ede9f12840eb941fe849643448348704b51
10:31.42 INFO: First bad revision: c6299be2356cc2bb10f3e1e7e6f04ed2004585d3
10:31.42 INFO: Pushlog:

Which points to bug 1424076.

Hence, 68 isn't affected.

Attachment #9135517 - Attachment is obsolete: true
Duplicate of this bug: 1528647
You need to log in before you can comment on or make changes to this bug.