A community site renders user-submitted links with `target="_blank"`. Explain reverse tabnabbing through `window.opener`, and what you would do about it given how browsers behave today.

## What window.opener is When a document opens a new browsing context — through `<a target="_blank">`, `<form target="_blank">` or `window.open()` — the new context's `window.opener` references the opener's `WindowProxy`. That reference survives navigation in the new tab and is a normal part of the platform: OAuth popups, print helpers and "open in a new tab and post the result back" flows depend on it. The same-origin policy applies to it in the usual asymmetric way. Cross-origin, the opened page cannot read `window.opener.document`, cookies, or any script state. But a handful of `Window` members are deliberately cross-origin accessible, and one of them is **writing** `location`. Assigning `window.opener.location = url` is a navigation request, and navigating a window you have a handle to has always been permitted. ## The attack Reverse tabnabbing exploits exactly that asymmetry plus a human factor: users do not re-verify a tab they already had open. 1. An attacker posts a link on your forum. A user clicks it; it opens in a new tab with `target="_blank"`. 2. The attacker's page runs `window.opener.location = 'https://forum-example.attacker.test/session-expired'` — a pixel copy of your login page. 3. The user reads the linked page, closes or switches away from it, and returns to what they believe is the tab they left. 4. They see "your session expired, please sign in" and type real credentials into the attacker's page. Nothing about the original tab visibly changed except its URL, which nobody re-reads. The attack needs no XSS on your site and no interaction beyond a click on a link you rendered. A related, milder issue is that without `noreferrer` the destination receives a `Referer` header disclosing the page the user came from, which can leak a private URL. ## The fixes `rel="noopener"` on the anchor makes the new context's `window.opener` **null**, so there is nothing to navigate: ```html <a href="https://untrusted.example/thread" target="_blank" rel="noopener noreferrer"> User-submitted link </a> ``` `rel="noreferrer"` is a superset: it also suppresses the `Referer` header, and it implies `noopener`. For links to third-party content that a user submitted, both together is the sensible default; for links to a partner who needs the referrer for attribution, `noopener` alone. For script-opened windows, the token goes in the *features* string, which is the part people forget: ```js const win = window.open(url, '_blank', 'noopener'); // win is null — with noopener there is no handle to give back ``` That `null` return is the tell that it worked, and also the reason the pattern of `const w = window.open(...); w.opener = null;` is inferior: it runs after the context exists, does not apply if the new page navigates first, and depends on your script running at all. ## What changed in browsers Browsers eventually made the safe behaviour the default for anchors. As of the current major browsers — the change landed in Chrome 88, Firefox 79 and Safari 12.1 — a link with `target="_blank"` implies `noopener` unless you explicitly opt back in with `rel="opener"`. `window.open()` was deliberately **not** changed, because its return value is the whole point of calling it and defaulting to `null` would have broken popup flows across the web. So the current posture is: anchors are safe by default in modern browsers, but you still write `rel="noopener noreferrer"` on untrusted links because it is free, it documents intent, it protects users on old clients, and it survives markup being copied into a context where the default does not apply. ## The rest of the hardening for user-submitted links The opener problem is one of a family, and a senior answer covers the neighbours: - **Validate the scheme.** Allow `http:` and `https:` (and possibly `mailto:`); reject `javascript:` and `data:` hrefs outright, since those execute in *your* origin. Parse with `new URL(href, location.href)` and check `protocol`. - **Do not surface a link's real destination only in the status bar.** Displaying the resolved hostname next to the link text blunts lookalike domains. - **Keep the tradeoff in mind for `noopener`.** Dropping the opener relationship allows the browser to open the new page in a separate process, which is a small memory cost and a performance benefit; it also breaks any legitimate flow that expects to post back to the opener, which is why the token belongs on untrusted links rather than blanket-applied to your own OAuth popups. The short form for an interview: `window.opener` lets an opened page navigate the tab that opened it, that is enough for a credible phishing swap, `rel="noopener"` removes the reference, anchors have defaulted to it for years now, and `window.open` still needs it passed by hand.