Reverse Tabnabbing: How window.opener Still Creates Phishing Bugs
Reverse tabnabbing is when a page you open with target="_blank" keeps a handle to your window via window.opener and navigates your tab to a phishing page while you look at the new tab.
Modern browsers increasingly default to noopener, but older apps, in-app browsers, and careless frontend code still ship vulnerable links.
How to test
- Find outbound links with
target="_blank"lackingrel="noopener noreferrer". - If you can host the destination (or use a program-approved PoC page), have it run
window.opener.location = 'https://your-poc'. - Confirm the original Bugflare/program tab navigates.
Only test against pages you control or that the program allows.
Impact today
- Phishing the opener origin’s users (credentials, OAuth)
- Partial session UX confusion on sensitive dashboards
- Severity is often medium unless chained with a convincing spoof of the real UI
Be honest: Chromium’s default noopener reduced severity on many targets. Still report when the app opts back into opener access or supports older WebViews.
Report tips
Show the HTML/window.open call, missing noopener, and a recording of the opener navigation. Suggest rel="noopener noreferrer" and window.open(url, '_blank', 'noopener').
Defensive checklist
- Add
noopener noreferreron all_blanklinks. - Prefer framework defaults that strip opener.
- Avoid
window.openeraccess unless required. - Test in-app browsers and legacy Electron shells separately.
Tabnabbing is a UX-trust bug. When the original tab changes under the user, phishing writes itself.
Original Bugflare guide informed by OWASP reverse tabnabbing guidance.