Closed Bug 1094449 Opened 6 years ago Closed 6 years ago

links opened with rel="noreferrer nofollow" do not set window.opener to null, send over referrer information


(Core :: DOM: Navigation, defect)

33 Branch
Not set



Tracking Status
firefox36 --- fixed


(Reporter: kennysanx, Assigned: bzbarsky)




(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141027150301

Steps to reproduce:

Visit in Firefox 33/Firefox Beta 34
click on the link

Actual results:

Clicking on the link opens a new tab to which contains a script that sets window.opener.location =, which sets the parent tab location to

Observe in the net inspector that referrer information is transferred in the request, and window.opener is not set to null. If you edit and change the link attribute to only rel="noreferrer", clicking on the link does not transmit referral info and also sets window.opener to null.

Expected results:

1) No referrer information is transmitted in the request to open
2) window.opener is set to null
3) The parent window ( should not redirect to
Component: Untriaged → Document Navigation
Product: Firefox → Core
Looks like nsDocShell::OnLinkClickSync is checking for the attribute value being "noreferrer".  It should be checking that one of the tokens in the value is noreferrer.

I don't think this is a security bug, fwiw.
Ever confirmed: true
Hey Boris sorry--I agree that this isn't particularly sensitive. This is my first time submitting a bug to Mozilla and I didn't really reflect too much on that checkbox at the end.
No need to apologize.  It's not obvious that this is not a security bug (which is why I haven't unchecked the checkbox; I _think_ this is not an issue we need to keep hidden, but I could well be wrong).

And thank you very much for reporting this, by the way!
Please remove the sec-other keyword if you think this may be a security issue after all.
Keywords: sec-other
Keywords: sec-other
Keywords: sec-other
Assignee: nobody → bzbarsky
Comment on attachment 8526517 [details] [diff] [review]
Treat @rel on anchors as a set of space-separated tokens, not a single token

bah, I should have caught this while reviewing.
Attachment #8526517 - Flags: review?(bugs) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Bug 530396 landed in Firefox 33, is it worth uplifting this fix?
Blocks: 530396
Group: core-security
Keywords: sec-other
Now that we have this fixed it would be nice to have this in release notes.

[Why is this notable]:
This is a great privacy feature if you link to a (external) site on blog or forum posts.

[Suggested wording]:
Support for the rel="noreferrer" attribute added

[Links (documentation, blog post, etc)]:

(In reply to :Gavin Sharp [email:] from comment #9)
> Bug 530396 landed in Firefox 33, is it worth uplifting this fix?

For Firefox 33 it's to late, but we should ship this fix to release soon. I think this feature will be primarily used on external links and mostly they open in a new tab. So a lot of people run in this issue.
relnote-firefox: --- → ?
Added to the 36 release notes with "Link rel="noreferrer" attribute implemented" as wording.
That's not the right wording.  rel="noreferrer" was implemented in firefox 33.

The right wording for this bug is:

  Fix bug with rel="noreferrer" being ignored if the rel value contains other tokens as
Flags: needinfo?(sledru)
ok. That is not worth release notes that. Thanks.
Flags: needinfo?(sledru)
You need to log in before you can comment on or make changes to this bug.