Menu
I know you can use "noopener" with window.open, which explicitly tells your browser to forbid the child window from accessing the parent window. This should have the affect of using rel="noopener" in a hyperlink.
However, Chrome 88 is soon (2021?) going to make "noopener" the default.
So is there a way to do the opposite, and explicitly set it to "opener"? So that the child window DOES have access to the parent window? I'm hoping to fix my link before it breaks with the newest Chrome.
I assume it'd be the code below? I'm not sure how I'd test this before the next version of Chrome releases. But I also don't want to wait to make this change until after my link breaks with the next release.
window.open(url,'_blank','toolbar=1,menubar=1,location=1,status=1,scrollbars=1,opener')
or
window.open(url,'_blank','toolbar=1,menubar=1,location=1,status=1,scrollbars=1', 'opener')
405
That's where noopener and noreferrer come in. The values noopener and noreferrer belong to the rel attribute, and they tell the browser NOT to set the window. open property when opening a link in a new tab/window.
rel=”noopener” is an HTML attribute that's added to all WordPress links that are selected to open in a new browser tab. It is also accompanied by a rel=”noreferrer” attribute. This feature was introduced in WordPress to address a security vulnerability which can be exploited by malicious websites.
The noopener is needed to enhance the security of your website and prevent other websites from gaining access to your page (through the browser session). The noreferrer is used to protect referral information from being passed to the target website and this also hides referral traffic in Google analytics.
What Are rel=”noopener”, rel=”noreferrer”? rel=”noreferrer” indicates that no referrer information should be leaked when the link is clicked – browser will not send an HTTP Referrer header if someone clicks the link. HTML5 specs has full description of this attributes :
Another approach that will solve this in one line is to access the opener property directly and set it to null to make use of the fact that window.open () returns a Window object. This will work across all browsers to open a new tab with a null window.opener.
The two ways to do this are using anchor tags with the target attribute set to the new window's name: The other way is via JavaScript using window.open: window.open ("external url"); As you can imagine this opens up a variety of potential security issues.
When you add a link in WordPress you have the choice to select if the link will open in the same window or in a different one. When you select to open on another window, WordPress automatically adds the rel=”noopener” attribute to your HTML along with the usual, target=”_blank” attribute.
The HTML specification is clear about this, you can check it here.
I will share the first segment of the window.open steps:
The window open steps, given a string url, a string target, and a string features, are as follows:
If the event loop's termination nesting level is nonzero, return null.
Let source browsing context be the entry global object's browsing context.
If target is the empty string, then set target to "_blank".
Let tokenizedFeatures be the result of tokenizing features.
Let noopener and noreferrer be false.
If tokenizedFeatures["noopener"] exists, then:
Set noopener to the result of parsing tokenizedFeatures["noopener"] as a boolean feature.
Remove tokenizedFeatures["noopener"].
If tokenizedFeatures["noreferrer"] exists, then:
Set noreferrer to the result of parsing tokenizedFeatures["noreferrer"] as a boolean feature.
Remove tokenizedFeatures["noreferrer"].
If noreferrer is true, then set noopener to true.
You can see also in this bug tracker, which is tied to the commit that added that, that the edit is only concerned with anchors. I quote
Anchor target=_blank implies rel=noopener
The reason this edit is only done in anchors is because using window.open to trigger this attack would fall into XSS since it requires injecting JavaScript code.
The security issue this bug is concerned with, is that a user can put bad code in a page that you refer to but don't have access to. You can see it doesn't require Same Origin here. Another possible attack vector is when there is user-generated content on your website but this is unlikely since you are likely to escape the user input for XSS.
Final note, this edit is already available for you to test in Chrome Canary.
132
I do not know how to test this to confirm it works 100% but according to the docs for window.open, the windowFeatures parameter can be passed as comma-separated key-value pairs where you have key=value so you can do noopener=false. If you do this in the current chrome version then the window.opener of the new window is actually the previous window as if you hadn't set anything so I would assume that would work in the new chrome version when it comes out.
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
