DEV Community

Cover image for A down-to-earth explication of the noopener noreferrer attributes
Elisabeth Leonhardt
Elisabeth Leonhardt

Posted on • Updated on

A down-to-earth explication of the noopener noreferrer attributes

Lately, I have been using the attributes noopener and noreferrer a lot, and I caught myself looking them up on google several times because I couldn't remember them. The fifths time, I had to admit that I never understood what they meant.
So like every good developer, I asked google about it, but I didn't find so many easy-to-understand answers. After some reading, I decided to share my own explanation:

The noreferrer attribute

An analogy

Imagine yourself visiting a new city. You checked in at a cozy hotel and even got a restaurant recommendation from the receptionist. After a day of sightseeing, you have a delicious dinner at that restaurant. While you are paying, the waiter asks you if you enjoyed the meal and how exactly you found out about their restaurant. You are in a good mood and tell the waiter about the recommendation from your hotel. The restaurant now has some referral information from you: if they ask every customer the same question, they can determine how most of their customers know about them.

The technical meaning

The noreferrer attribute on link tags works like asking a customer how he found out about a service or a place. If you have some site analytics on your page, you can see what pages people came from before they clicked on a link that led them to your site. Dev.to for example gives me a dashboard that lets me know how many of my readers come from google or the dev.to platform itself. If there is no referrer information, it is assumed that the user entered the page directly. In technical terms: "The noreferrer link type hides referrer information when the link is clicked".

The noopener attribute

An Analogy

You are again in a new city, but this time it's for business, not for pleasure. That's because you are a secret agent working for the (British?) government and are working on a very secret assignment. After a long day of spy-work, you visit a restaurant that was recommended to you by the hotel receptionist. For security reasons, you don't want anybody to know where you are staying, so when asked, you say you just entered the restaurant because it looked nice from the outside (noreferrer), but unfortunately, you forgot a hotel receipt in the pockets of your coat which discloses your room number. An undercover spy posing as a waiter picks up your coat from the entrance area, gets access to your hotel key, and injects some deadly poison into the bottle of Don Pérignon in your hotel room. By the time you leave the restaurant, you overhear a discussion about a waiter taking a very long smoking break but you are immersed in thoughts about your assignment and write it off as nothing unusual.

Getting technical

Every page you open has a browsing context to render the document and everything inside it (aka. the page you are looking at). Besides, every browsing context has an attribute called "opener browsing context", which can be null or another browsing context (another page).

When you are looking at Google's Search Results, the page you are viewing has a Browsing Context. When you right-click on any of the results to open it in a new tab, a new Browsing Context is created which shows the search result, for example, my article. Now, the Browsing Context that shows my article has an attribute: the opener browsing context. That's basically just the page that opened the current tab, in this case, the google results.

Browsing context illustration

The problem here is that the browser context can manipulate the opener browsing context (dev.to could modify the tab with googles search results). This is called "reverse tabnabbing" and can enable phishing attacks. If the opener browsing context is the page of your bank, the target tab could redirect the browsing context to a page that looks like your bank's login page, and steal your account credentials once you log in.

The noopener attribute sets the opener browsing context in the target tab to null, therefore avoiding the possibility of tabnabbing.

I hope the analogy is clear: While you browsing a new tab (eating in the restaurant), somebody in the new tab (the undercover waiter) accesses the previous tab (the hotel) and modifies it in a malicious way (injects poison in your Champaign).

So which attributes should I use?

If you want to behave like a spy

If you are adding external links to your page but don't want your page to show up as a referrer in their analytics and also want to avoid reverse tabnabbing, use rel=noreferrer. As per MDN documentation, this will not leak referrer information and also set the opener browsing context to null in the new tab.

If you want to behave like a tourist

In the case that you don't mind sending referrer information to an external page but want to avoid reverse tabnabbing (which you should), only add rel=noopener to your link tags. This will still send the referrer header.

tag attribute Referral Header Reverse Tabnabbing prevention
noreferrer
noopener
no tag ✅ (for modern browsers)

Since the risk for reverse tabnabbing is something that should be avoided altogether, the noopener attribute is now automatically set for all external links by modern browsers, but I will still continue using it, just to be sure.

I hope this gave you a better idea of how these two attributes work and why to use them. Have a great week everybody!

Top comments (2)

Collapse
 
aritdeveloper profile image
Arit Developer

GREAT relatable explanation! Thank you for sharing!

Collapse
 
frontenddeveli profile image
Elisabeth Leonhardt

Thank you! Glad you liked it ☺️