Optionally add noreferrer to external links

(Brett Zink) #1

The 1.7 release notes mention that noreferrer was added. I don’t see it in the options or in the codebase anywhere.

I categorized this as support, because maybe i’m missing the config somewhere? But maybe it’s a bug?

(Régis Hanol) #2

It has been removed a while ago

@techAPJ do you remember why?

(Jeff Atwood) #3

I vaguely remember, mostly I think because it is pointless?

  • noopener is for security

  • nofollow is for search engine safety

  • noreferrer … has no purpose other than “screw you, we’re not sending the referrer” … plus http to https doesn’t send it anyway.

There is a pretty weak case to be made for it in terms of intranet leakage, but I would be unwilling to spend any engineering time on this unless a few paying customers request it.

(Sam Saffron) #4

This can be achieved quite easily with a theme component if someone really wants this.

(Arpit Jalan) #5

Sorry, I can’t remember exactly why I removed it. There must be a discussion for it here on meta but I am unable to find it right now.

(Jeff Atwood) #6

Speaking of referrers


(Kane York) #7

For a dynamic web app like Discourse, referer policy is probably more useful to be set at a page scope rather than for individual links.

To dynamically set referer policy, use the <meta> element, and the last set policy prevails, which makes it very easy to code.

An example policy:

  • " no-referrer-when-downgrade " by default
  • " strict-origin-when-cross-origin " when viewing private messages or secure categories

With a site setting to change it to always be “strict-origin-when-cross-origin”, turned on by default for login required sites.

If we decide Discourse doesn’t need its own referer information, strict-when-cro can be upgraded to “strict-origin” to save bandwidth.


I’m curious, why is rel="noopener" added in oneboxes but not normal external links?


They also seem to be missing in the user-card.

(Jeff Atwood) #9

Possibly an oversight cc @techapj

(Arpit Jalan) #10

rel="noopener" not being added in normal external links is actually correct behaviour because @codinghorror is TL4 and tl3 links no follow is disabled.

rel="nofollow noopener" being added for @zogstrip (TL4) is a bug and onebox should respect the site setting tl3 links no follow.

There is a bug report for this here:

If the user is TL3 or above, rel="nofollow noopener" not being present is correct / as expected.

(Arpit Jalan) #11

Fixed via:


This seems to be a no-brainer: Why not trust a link that someone posted who is trusted by Discourse? But I was thinking about it a little more and this is the wrong question.

How can you or @codinghorror or anyone be certain that the external site isn’t compromised? And if not now can’t it be malicious at some point in the future?

So it’s not about trusting the user who posted the link but rather trusting the target site.

Tell me that i’m wrong.

(Jeff Atwood) #13

Then it sounds like you want a generic “warn that you are visiting an external website and there might be dragons” pop-up on clicking any link… not really a fan of that, but it is discussed here.