External Links Vulnerable to Tabnabbing: How to Fix It

What this check flags

The crawler found links on your site that open in a new tab using target="_blank" but do not carry rel="noopener" (or rel="noopener noreferrer"). Security tools call that combination "reverse tabnabbing." It is a long-standing item on checklists like the OWASP Web Security Testing Guide, so crawlers keep reporting it even though browser defaults have improved.

How tabnabbing actually works

When a visitor clicks an external link set to open in a new tab, the page that loads there historically received a JavaScript reference back to the page it came from: window.opener. With it, the new page could change where the opener navigates by setting window.opener.location.

Picture it from the visitor's side. They click an external link on your article and a new tab opens. While they read that tab, a script on it silently rewrites your original tab to a copycat login page on a domain the attacker controls. The visitor flips back to what they believe is your site, sees a login prompt, and types their credentials straight to the attacker because they were on your domain a moment ago. They never did anything wrong beyond clicking a normal-looking link.

The dangerous part is the trust transfer. The attacker does not need to break into your server. The link just needs to point somewhere they control, and your page needs to be reachable through window.opener.

The modern-browser default (be honest about this)

An honest fix-guide has to give you the full picture: browsers closed this hole on their own. Safari shipped the change at the end of 2018, Firefox in mid 2020, and Chromium at the end of 2020. By 2021 the HTML standard itself said an anchor with target="_blank" should behave as if rel="noopener" were set, and the major browsers followed it. In a current browser, window.opener comes back null for these links whether or not you wrote the attribute.

So if every visitor is on an up-to-date Chrome, Firefox, Safari, or Edge, the classic tabnabbing redirect is already blocked for them. That is why this issue sits lower on the priority list than it did five years ago.

Why it is still worth fixing

Lower risk is not zero risk, and "the browser handles it" is a fragile thing to lean on. Older and embedded environments do not all carry the new default. Out-of-date browsers, some in-app webviews, and non-mainstream rendering engines may still expose window.opener, and you do not control what your visitors browse with. Writing the attribute makes the protection explicit instead of conditional.

It also stops the audit flag from reappearing on every crawl, which matters when you are trying to get a report to a clean baseline. A page full of unresolved warnings hides the ones that actually need attention.

How to fix it

Add the rel attribute to every link that uses target="_blank". Here is the before and after.

<a href="https://example.com" target="_blank">Visit example</a>

<a href="https://example.com" target="_blank" rel="noopener noreferrer">Visit example</a>

Now the difference between the two keywords, because people lump them together:

noopener is the security fix. It severs the window.opener link so the new tab cannot reach back and navigate your page. This is the keyword the tabnabbing check cares about.

noreferrer severs the opener too, and additionally strips the Referer header so the destination cannot see which page sent the visitor. It is a privacy choice layered on the security one. Many teams write both as rel="noopener noreferrer" and move on.

On WordPress, the block editor already adds rel="noopener" when you tick "open in new tab," so most flagged links come from raw HTML blocks, page-builder modules, theme templates, or imported content. Fix them at the source so the attribute survives the next edit.

How to diagnose which links are affected

View the page source, search for target="_blank", and check each hit for a rel containing noopener. To do it in bulk, run this in the browser console:

document.querySelectorAll('a[target="_blank"]:not([rel~="noopener"])')
  .forEach(a => console.log(a.href));

That prints every link on the current page that opens a new tab without noopener. A site crawler does the same job across every URL at once, which is how this report found them.

Common mistakes

Putting rel on the wrong links. You only need it where target="_blank" is present; same-tab links have nothing to sever.

Overwriting an existing rel. If a link already carries rel="nofollow" or rel="sponsored", append rather than replace: rel="nofollow noopener". The keywords are space-separated and stack fine.

Assuming the browser default covers you everywhere. It covers current mainstream browsers, not every webview or legacy client your audience might use.

Fixing the rendered page but not the template. If the link comes from a theme file or builder module, patch the source or every other instance stays flagged.

FAQ