New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 35 users

Issue metadata

Status: Assigned
Buried. Ping if important.
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocked on:
issue 551884

Sign in to add a comment

Issue 168988: Security: if window.opener exists, a page can trigger a navigation in the opener regardless of security origin

Reported by, Jan 9 2013 Project Member

Issue description


<a href="b.html" target="_blank">link</a>



When the user goes to a.html and clicks the link, a new tab with b.html is opened, and the old tab with a.html navigates to in the background.

Note that this also works when a.html and b.html are on different security origins.

can be used to annoy the user.

Or get the referrer if the tab was opened without a referrer.

Comment 1 by, Jan 9 2013

Status: Assigned
@creis - i know this is a duplicate, but I can't seem to find the original report.  thanks.

Comment 2 by, Jan 10 2013

Yep, we also saw this in  issue 156712 .  Before I close it as a dupe, I want to confirm whether my understanding of the spec is correct or not.  I thought it was required to allow cross-origin windows to navigate their opener, but perhaps it's not.

Comment 3 by, Jan 10 2013

Interesting.  We may look into locking this down.

The current wording of the spec doesn't allow a cross-origin page to navigate its opener:

That seems to apply both to navigations of named windows and things like the location.href setter.

Other browsers (including Safari, Firefox, IE, and Opera) all behave the same as Chrome here, so we may need to get a sense for the compatibility impact of changing this.  Worth a try to lock it down, though.

Note that I may not have time to get to this right away, so someone else should feel free to grab it if they have the time.

Quote from the spec:
A browsing context A is allowed to navigate a second browsing context B if one of the following conditions is true:
 - Either the origin of the active document of A is the same as the origin of the active document of B, or
 - The browsing context A is a nested browsing context with a top-level browsing context, and its top-level browsing context is B, or
 - The browsing context B is an auxiliary browsing context and A is allowed to navigate B's opener browsing context, or
 - The browsing context B is not a top-level browsing context, but there exists an ancestor browsing context of B whose active document has the same origin as the active document of A (possibly in fact being A itself).

Comment 4 by, Jan 10 2013

If all browsers allow cross-origin windows to navigate their opener, but the spec does not, then I'd bet that the spec is just incorrect :-/

Comment 5 by, Jan 30 2013

Can this be closed as Won't Fix or do we intend to change behavior here?

Comment 6 by, Jan 31 2013

I'd like to look into some UMA data for how many pages we would affect if we locked it down.

I would be ok with marking this as Feature-Security and lifting the view restriction, though, since the current behavior is somewhat expected and on par with all browsers.  @cdn, do you agree?

Comment 7 by, Jan 31 2013

Labels: -Restrict-View-SecurityTeam -Type-Security Feature-Security Type-Bug
Sounds good

Comment 8 by, Mar 10 2013

Project Member
Labels: -Feature-Security -Area-WebKit Cr-Content Cr-Security

Comment 9 by, Apr 5 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 10 by, Jan 5 2015

Hey everyone,

This is a pretty huge issue for any site that deals with user-generated content. There's a pretty gnarly attack scenario enabled by this behavior:

1. Go to a UGC site that allows uploading files with embedded links.
2. Upload a file containing a link to an attacker's page.
3. When someone clicks the link, the attacker page redirects the original window to a page that looks like the UGC site but is actually a phishing site designed to look like it. The user doesn't notice this because focus is on the attacker's page in the new window while the redirect happens.

I don't want to speak for others, but this seems like a pretty big security hole that is important to close

Comment 11 by, Jan 6 2015

This is also an issue on a page that allows user commenting with anchor links. When someone else clicks on the link, the destination can easily change the original page with window.opener.location.replace() to show a different page that looks like the original page or one that asks for login credential.

Comment 12 by, Jan 6 2015

For the record, it looks like the spec's wording has changed and now allows cross-origin openers to be navigated.  Here's an updated quote from

"A browsing context A is allowed to navigate a second browsing context B if the following algorithm terminates positively:

If A is not the same browsing context as B, and A is not one of the ancestor browsing contexts of B, and B is not a top-level browsing context, and A's active document's active sandboxing flag set has its sandboxed navigation browsing context flag set, then abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is one of the ancestor browsing contexts of A, and A's node document's active sandboxing flag set has its sandboxed top-level navigation browsing context flag set, then abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is neither A nor one of the ancestor browsing contexts of A, and A's Document's active sandboxing flag set has its sandboxed navigation browsing context flag set, and A is not the one permitted sandboxed navigator of B, then abort these steps negatively.

Otherwise, terminate positively!"

The spec now defaults to allowing the navigation, which seems to be consistent with existing browser behavior.  I'm not opposed to seeing that changed, but someone would have to find the time to measure the compatibility impact.

Comment 13 by, Jan 7 2015

Agreed that this is very risky and unfortunate for the many sites that allow user-supplied links.  It forces an additional script-driven redirect interstitial page to be loaded in every new tab to disown the opener before navigating to any untrusted content, which has unacceptable performance implications.

Comment 14 by, Jan 7 2015

Comment 13: That's not quite correct.  A page can put rel=noreferrer target=_blank on untrusted links to force them to open in a window with no opener, and Chrome will even try to put them in a separate process.  Alternatively, it can use;w.opener=null;w.location.href=url; without any extra navigations.

Comment 15 by, Feb 24 2015

@14 - will trigger the popup blocker, so it's not an equivalent "alternative" to an anchor link.

Comment 16 Deleted

Comment 17 by, Jun 16 2015

FYI, I have submitted a proposal which will address this in the HTML spec.

I welcome support in developing a standardized way of fixing this sort of vulnerability.

Comment 18 by, Jun 16 2015

Note: The W3C version is not the canonical one (most) UAs use.

I believe you want to file against the WHATWG HTML Living Standard ( ) - in particular, the "File a bug" process described there (which, incidentally, points back to a W3C hosted bug tracker, which is several orders of magnitude more than the Github pull request)

Comment 19 by, Jun 16 2015

Thanks for the tip rsleevi... I've filed

Comment 20 by, Nov 6 2015

Blockedon: chromium:551884
Labels: -Type-Bug Type-Feature Cr-Blink-SecurityFeature
Charlie, did you add metrics for this? It does seem like a default that we might want to find a way to reverse. In the meantime,  issue 551884  covers a more explicit way of doing the `rel=noreferrer target=_blank` trick to block access to `window.opener` (and to allow us to do clever things with processes).

Comment 21 by, Nov 9 2015

@mkwst: No, I never had the chance.  Comments 3, 6, and 12 sum up my current understanding.  Feel free to take it over, as I'm not likely to have the time in the near future (though it would be great to lock down if we can).

Comment 22 by, Dec 10 2015

Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.

Comment 23 by, Jan 8 2016

Labels: Cr-UI-Browser-Navigation
This has come up again in issue 574958, so it might be worth revisiting.  mkwst@, would you have time to take a look at whether navigations of cross-origin openers should be denied?

Comment 24 by, Jan 8 2016

Also adding alexmos@ for his take, since I know he's looked at this part of the spec recently.

Comment 25 by, Jan 11 2016

Issue 574958 has been merged into this issue.

Comment 26 by, Jan 11 2016

I'm pretty sure that this is the specced behavior. I'm also pretty sure that I don't like it and that we should change pieces of it if possible. I'll try to get some metrics in for this milestone.

Comment 27 by, Jan 11 2016

(Also note that did land, so `noopener` is a totally valid workaround for the existingly annoying behavior.

Comment 29 by, Jan 11 2016

IMO it doesn't matter if it's specced behavior or not. And 'noopener' workaround is probably not very common or widely used. The truth is that Chrome has a huge security issue which allows to replace trusted sites in browser tabs with malicious ones, which makes it "phising paradise". It may pretend Google, or Facebook, or your banking site and ask to re-enter credentials etc. Just click a wrong banner or link - and you are in trouble.
It's very sad to find "gems" like this one in Google Chrome, and even more sad to find out that the problem was known but ignored for more than a year.
"Secure browser" ya say? 8b

Comment 30 by, Mar 15 2016

FWIW, I made a quick “explainer” document/demo for this feature:

Mike, can this issue be closed now that Chrome 49 shipped with this feature?

Comment 31 by, Mar 18 2016

What about <form ... target="_blank">?

Probably much less common but seems to be affected, too.

Comment 32 by, Mar 18 2016

Re: comment 31: if you allow `<form>` in user-generated content, you have bigger problems.

Comment 33 by, Aug 25 2016

There are about 140+ comments about this issue on the reddit thread here: -- almost seems like a consensus that rel="noopener" should become the default.

Is it possible to change the default to noopener, and add a setting so that outdated/legacy applications can have users manually toggle this behavior back on?  IMO this is the wrong default behavior for the browser because it is a huge phishing issue.  Main reason I can see to persist it is if Chromium developers have some kind of conflict of interest wherein they derive some income from phishing sites.

Comment 34 by, Aug 26 2016

I agree. This would overall be more beneficial in terms of security than it would be detrimental in terms of backward compatibility, so it's worthwhile to adjust the default behavior to something which obeys cross origin policies.

Comment 35 by, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 36 by, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 37 by, Jan 28

I'm just curious about this issue. Has this actually been fixed? I'm running Chrome 71 and I can still verify the exploit in my browser as documented in

Comment 38 by, Jan 28

RE: #c37: stepheneliotdewey@

Can you please provide more detailed repro steps?  Does the link (i.e. the anchor element) you are using for the repro have a rel=noopener attribute?

FWIW, I tried to
1. Navigate to
2. Click the link/button labeled: "Click me!!1 (now with rel=noopener)"
Actual behavior I observed was:
- A new tab opened with (same-origin as the opened)
- The new tab had the following message: "The previous tab is safe and intact. window.opener was null; mischief not managed!"
- The new tab was hosted in a renderer process separate from the opener (verified using Chrome Task Manager - Shift+Esc)
- |window.opener| in the new tab was null (verified using DevTools console)

Sign in to add a comment