1709797 - Document.referrer being set inconsistently (private and not-private browsing)

Status: NEW

(Core :: DOM: Security, defect, P2)

Description

[Brendan]

Attachment: firefox_document_referrer.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36

Steps to reproduce:

I have a react-app that is linked to from a website (click on link on website A which directs user to website B containing react app).

Expected:
When user clicks on link, react app checks document.referrer property to make sure user was directed from website A. If user is not directed from website A or document.referrer is empty (in the case of a bookmark being clicked or page reloaded), then user is redirected to error page on website B.

Actual:
On firefox, when user clicks on link in a normal browsing tab and is redirected to react app (website B), the document.referrer property is empty ("").

Actual results:

Downgraded to older version of firefox (fresh install) and opened up a single link to be directed to website B, everything loads fine and document.referrer is set, but when tab is closed and link is clicked a second time, document.referrer is no longer set and returns an empty string (" ").

Then tried opening up a private session ("New Private Window" on Firefox) and repeated above steps (click on link to be redirected to website B) and document referrer was set, closing link and clicking on it again, document referrer still gets set.

Expected results:

When clicking on a link which redirects to website B, document.referrer must be set.

It seems that some policy is blocking document.referrer being set on a normal tab, but in private browsing this issue does not exist.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

I think bug 1589074 made document.referrer to not set by default when cross-origin and thus an explicit Referrer-Policy: strict-origin header is required to keep the previous behavior. Anne, could you confirm?

Comment 3

[Anne (:annevk)]

Kagami, no, the new default should still show the origin of the originating URL, just not the path and query. (Exception is secure to insecure, but it never survived there.)

Dimi, can you investigate this?

Comment 4

[Dimi Lee [:dimi]]

(In reply to Anne (:annevk) from comment #3)

Dimi, can you investigate this?

Yes. I can reproduce the bug while navigating to the site in attachment. It looks like we don't get ReferrerInfo somehow. I'll look into this.

Comment 5

[Dimi Lee [:dimi]]

Yes. I can reproduce the bug while navigating to the site in attachment. It looks like we don't get ReferrerInfo somehow. I'll look into this.

So it seems that we don’t set ReferrerInfo when a channel is intercepted by a ServiceWorker. If i navigate to https://digiinskryf.atkv.org.za/ for the first time (while ServerWorker is not yet registered), I can see document.referrer returns the correct referer. But after ServiceWorker is registered and we navigate to the page again, document.referrer returns empty. This also explains why we don’t have this issue in private browsing mode (we don’t support ServiceWorker in pb mode). BTW, I can reproduce this bug at least from FF80 (I didn't try earlier version).

If i understand correctly, for a normal document channel load, we set the ReplacementChannelConfig here
https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#1401-1408,
which eventually leads us to
https://searchfox.org/mozilla-central/rev/716d7cd80b3dcd81c005ad13b51d3e6a85bd7e73/netwerk/protocol/http/HttpBaseChannel.cpp#4284-4288
to set the ReferrerInfo in the channel

However, in the case of a channel that is intercepted by ServiceWork, the channel is an InterceptedChannel, not a nsHttpChannel, hence the ReplacementChannelConfig in here is not set, and then we can't get the referer from the channel. I'm not sure if we should also set ReplacementChannelConfig for InterceptedChannel or this should be done somewhere else.

Hi Christoph, I guess we'll need necko team's help to figure out what the right solution is.