Tabnabbing and Clickjacking: The UI Attacks You Never See
Security & Privacy

Tabnabbing and Clickjacking: The UI Attacks You Never See

Some browser attacks don't need malware. They repaint your idle tabs or hide a button underneath a fake one, and you hand over credentials or approvals yourself. Learn how these UI tricks work.

BROWSER.LOL
19.03.2026
20 min read
Share

You have eleven tabs open. One of them, all the way on the left, was a half-written blog post two hours ago. You come back, see the familiar Gmail logo and an empty login screen politely asking you to sign in again. You type your password and 2FA code. The tab then opens your real Gmail and you notice nothing. The tab repainted itself while you were away; the attackers have your credentials.

Tabnabbing and clickjacking are the quietest attacks in the browser. They don't require clicking a suspicious link. They use the fact that you rarely watch your tabs actively and that a site in its own tab carries more authority than you'd think. The techniques are old, the channels are still open in 2026, and most protection advice is aimed at developers, not users.

What tabnabbing really does

Two browser tabs side by side, the left showing an incomplete page, the right a login page, with a dashed arrow pointing from left to right

A tab can reload itself while in the background. That's not a vulnerability, that's a deliberate browser capability. Someone on a page expecting an incoming email notification should still get pinged even when the tab isn't focused. Tabnabbing exploits exactly that.

Here's the shape of the attack. You visit an innocuous page, leave it open, and switch to another tab. The first page's script notices the switch (via the Page Visibility API or a focus event handler) and waits a few minutes. Then it changes the title, favicon, and HTML of the page. What was an article now looks like a Google, Microsoft, or GitHub login screen.

When you return, you see a familiar login screen in a tab you opened yourself. The URL in the address bar is still the original page's, but almost nobody checks it. The login form sends your input to the attacker and redirects you to the real Google afterward, so on the second try you just think your first attempt failed.

Clickjacking: one button, two identities

Clickjacking is a different UI trick. The attacker embeds a legitimate page (say, a change-password page or a "send money" form) inside an invisible iframe and overlays it with an attractive decoy: "Click to win". The user appears to click the decoy; the click actually lands on the real button below. The browser considers the click authorized because technically it is.

The classic case: a Facebook Like button in an iframe, overlaid with a game element. Victims "like" a page they never saw. It gets worse when the button below is "Confirm" on an OAuth consent screen or "Send transaction" in a decentralized app. Both have been exploited in the wild more than once.

A button labeled 'Click here' with a semi-transparent overlay of a second button labeled 'Win prize' covering it, both schematic

The defenders here are the site operators. The X-Frame-Options header and frame-ancestors in Content-Security-Policy forbid other sites from embedding the trusted site in an iframe. Big platforms have this covered. Sites that don't set the header stay exploitable, and new Web3 sites have historically been weak here.

Reverse tabnabbing via window.opener

A related technique is reverse tabnabbing. A newly opened tab has window.opener access back to the page that opened it. If an attacker sneaks a link onto your site, the new tab can redirect the original page. You switch back later and land on a phishing clone of the site you were actually on.

The protection is rel="noopener" on every external link, and modern browsers now apply it automatically for links opened in new tabs. That closes the classic vector, but forums and user-generated content sites remain vulnerable when they render user content loosely.

Why these attacks persist

UI attacks have three traits that make them durable. First, they're usually subtle violations of conventions, not of technical rules. Repainting a tab is a legitimate browser capability; embedding an iframe is too. Second, they lean on visual and situational habits that users don't actively monitor because they don't realize they follow conventions at all.

Third, they're cheap. A tabnabber is an HTML file with a few dozen lines of JavaScript. Attackers deploy dozens of variants in parallel, pair them with malvertising or SEO abuse, and lose nothing when one is detected.

11%

of the top 10,000 sites lack frame protection

30s

typical delay before a hidden tab repaints

4 years

since the most recent high-profile tabnabbing bug in a major app

What you can do about it today

Browsers and site operators own most of the mitigation. A few user habits close the rest of the gap.

  1. 1

    Be suspicious of login screens in unexpected tabs

    If a tab suddenly asks for a login you weren't expecting, close it. Reopen the service through a bookmark instead.
  2. 2

    Check the URL on every login form

    The address bar survives tabnabbing. A "Gmail" page on an unfamiliar domain is always fake.
  3. 3

    Keep sessions short

    The longer tabs stay open, the more opportunity they have to repaint. For sensitive services, long background tabs aren't a great idea.
  4. 4

    Do critical actions in their own isolated session

    When you grant OAuth consent, sign transactions, or link accounts, do it in a session where nothing else is running in parallel. That neutralizes the known UI tricks because no second tab can be manipulated alongside you.

Ready to unlock desktop power on any device?

Try Browser.lol free and experience true mobile productivity.

Start Your Desktop Browser

No downloads required • Works on any device

Used by 250k+ professionals
Full desktop compatibility
Instant setup

Latest posts

All posts