History of Clickjacking (2002–2025)

Clickjacking has become the persistent parasite of the modern web. The term emerged in the early 2000s, when Jeremiah Grossman and Robert Hansen described a deceptive scenario: tricking a user into clicking on something they cannot actually see. An optical illusion applied to code, it quickly became a mainstream attack technique (OWASP).

• 2002–2008: Emergence of “UI redressing”: HTML layers + transparent iframes trapping users (Hansen Archive).
• 2009: Facebook falls victim to Likejacking (OWASP).
• 2010: Cursorjacking emerges — shifting the pointer to mislead user clicks (OWASP).
• 2012–2015: Exploitation via iframes, online ads, and malvertising (MITRE CVE) (Infosec).
• 2016–2019: Tapjacking spreads on mobile platforms (Android Security Bulletin).
• 2020–2024: Rise of “hybrid clickjacking” combining XSS and phishing (OWASP WSTG).
• 2025: At DEF CON 33, Marek Tóth unveils a new level: DOM-Based Extension Clickjacking. This time, not only websites, but browser extensions (password managers, crypto wallets) inject invisible forms, enabling stealth exfiltration of secrets.

At DEF CON 33, Marek Tóth publicly revealed DOM extension clickjacking, marking a structural shift from visual trickery to systemic weakness in password managers and crypto wallets.

What is DOM-Based Extension Clickjacking? Definition, Attack Flow & Zero-DOM Defense

DOM-based extension clickjacking hijacks a password manager or wallet extension by abusing the browser’s Document Object Model. A deceptive page chains hidden iframes, Shadow DOM, and a malicious focus() to trigger autofill into an invisible form. The extension “thinks” it is on the right field and pours secrets—credentials, TOTP, passkeys, even wallet keys—straight into the attacker’s trap. Because secrets touch the DOM, they can be silently exfiltrated.

DOM extension clickjacking is not a trivial variant — it exploits the very logic of autofill password managers.
Here, the attacker does not simply overlay a button with an iframe; instead, they force the extension to fill out a fake form as if it were legitimate.

Typical attack sequence:

• Preparation — The malicious page embeds an invisible iframe and a hidden Shadow DOM to disguise the real context.
• Bait — The victim clicks on an innocent-looking element; a malicious focus() call silently redirects the event to the attacker-controlled input field.
• Exfiltration — The extension believes it is interacting with a valid form and automatically injects credentials, TOTP, passkeys, or even private crypto keys directly into the fake DOM.

This stealthy mechanism confuses visual cues, bypasses traditional defenses (X-Frame-Options, CSP, frame-ancestors), and turns autofill into a covert data exfiltration channel.
Unlike traditional clickjacking, the user is not tricked into clicking a third-party site — instead, the browser extension betrays itself by trusting the DOM.

Glossary

• DOM (Document Object Model): The browser’s internal structure representing page elements.
• Clickjacking: A technique that tricks users into clicking hidden or disguised elements.
• Shadow DOM: A hidden encapsulated DOM subtree used to isolate components.
• Zero-DOM: A security architecture where secrets never touch the DOM, eliminating injection risks.

Password Manager Vulnerabilities (2025)

As of August 27, 2025, live testing by Marek Tóth at DEF CON 33 confirms that most browser-based password managers remain structurally exposed to DOM extension clickjacking.

Out of 11 managers tested, 10 leaked credentials, 9 leaked TOTP codes, and 8 exposed passkeys.

In short: even the most trusted vault can become porous once it delegates secrets to the DOM.

• Still vulnerable: 1Password, LastPass, iCloud Passwords, LogMeOnce
• Patched: Bitwarden, Dashlane, NordPass, ProtonPass, RoboForm, Enpass, Keeper (partial)
• Actively working on fixes: Bitwarden, Enpass, iCloud Passwords
• Marked as “informative” (no fix planned): 1Password, LastPass

Status Table (Updated August 27, 2025)

CVE Disclosure & Vendor Responses (Aug–Sep 2025)

The discovery by Marek Tóth at DEF CON 33 could not remain hidden:
DOM-based extension clickjacking vulnerabilities are currently being assigned official CVE identifiers.
Yet, as often happens in vulnerability disclosure, the process moves slowly.
Several flaws were reported as early as spring 2025, but by mid-August,
some vendors had still not issued public fixes.

Vendor responses and patching timeline:

• Bitwarden — reacted quickly with patch v2025.8.0 (August 2025), mitigating credential and TOTP leakage.
• Dashlane — released a fix (v6.2531.1, early August 2025), confirmed in official release notes.
• RoboForm — deployed patches in July–August 2025 across Windows and macOS builds.
• NordPass & ProtonPass — announced official updates in August 2025, partially mitigating DOM exfiltration issues.
• Keeper — acknowledged the impact but remains in “under review” status with no confirmed patch.
• 1Password, LastPass, Enpass, iCloud Passwords, LogMeOnce — still unpatched as of early September 2025, leaving users exposed.

The problem is not only the patching delay but also the way some vendors minimized the issue.
According to security disclosures, certain publishers initially labeled the vulnerability as “informational,” downplaying the severity.
In other words: the leakage was acknowledged, but put in a gray box until media and community pressure mounted.

Technologies of Correction Used

Since the public disclosure of DOM Extension Clickjacking at DEF CON 33, vendors have rushed to release patches. Yet these fixes remain uneven, mostly limited to UI adjustments or conditional checks. No vendor has yet re-engineered the injection engine itself.

🔍 Before diving into the correction methods, here’s a visual overview of the main technologies vendors have deployed to mitigate DOM Extension Clickjacking. This image outlines the spectrum from cosmetic patches to sovereign Zero-DOM solutions.

Objective

This section explains how vendors attempted to fix the flaw, distinguishes cosmetic patches from structural corrections, and highlights sovereign Zero-DOM hardware approaches.

Correction Methods Observed (as of August 2025)

📉 Limits Observed

• Patches did not change the injection engine, only its activation triggers.
• No vendor introduced a structural separation between UI and secret flows.
• Any manager still tied to the DOM remains structurally exposed to clickjacking variants.

Correction Technologies Against DOM Extension Clickjacking — Technical and Doctrinal Analysis

📌 Observation

DOM Extension Clickjacking is not a bug, but a design flaw: injecting secrets into a manipulable DOM without structural separation or contextual verification.

⚠️ What Current Fixes Do Not Address

• No vendor has rebuilt its injection engine.
• Fixes remain limited to disabling autofill, filtering subdomains, or detecting some invisible elements.
• None integrates a Zero-DOM architecture that ensures inviolability by design.

🧠 What a Structural Fix Would Require

• Remove all dependency on the DOM for secret injection.
• Isolate the injection engine outside the browser.
• Use hardware authentication (NFC, PGP, biometrics).
• Log every injection in an auditable journal.
• Forbid interaction with invisible or encapsulated elements.

📊 Typology of Fixes

🧪 Doctrinal Tests to Verify Patches

To verify if a vendor’s fix is truly structural, security researchers can:

• Inject an invisible field (opacity:0) inside an iframe.
• Simulate an encapsulated Shadow DOM.
• Check if the extension still injects secrets.
• Verify if the injection is logged or blocked.

📜 Absence of Industry Standard

Currently, no official standard (NIST, OWASP, ISO) regulates:

• Extension injection logic,
• Separation of UI and secret flows,
• Traceability of autofill actions.

Systemic Risks & Exploitation Vectors

DOM extension clickjacking is not an isolated bug — it represents a systemic flaw. When a browser extension collapses, the fallout is not limited to a leaked password. Instead, it undermines the entire digital trust model, creating cascading breaches across authentication layers and infrastructures.

Critical scenarios:

• Persistent access — A cloned TOTP is sufficient to register a “trusted device” and maintain access, even after a full account reset.
• Passkey replay — The exfiltration of a passkey functions as a master token, reusable outside any control boundary. Zero Trust becomes an illusion.
• SSO compromise — A trapped extension in an enterprise leads to the leakage of OAuth/SAML tokens, compromising the entire IT system.
• Supply chain breach — Poorly regulated extensions create a structural attack surface at the browser level.
• Crypto-assets siphoning — Wallets such as MetaMask, Phantom, and TrustWallet inject keys into the DOM; seed phrases and private keys are drained as easily as credentials.

Regional Exposure & Linguistic Impact — Anglophone World

Not all regions share the same risk level when it comes to DOM-based extension clickjacking and Browser-in-the-Browser (BITB) attacks. The Anglophone sphere—thanks to high adoption of password managers and crypto wallets—represents a significantly larger exposed user base. Sovereign, Zero-DOM countermeasures are critical to safeguard this digitally dependent region.

🌍 Estimated Exposure — Anglophone Region (Aug 2025)

Sources: ICLS (English speakers), Security.org (US password manager usage), DataReportal (UK digital statistics).

Exposed Crypto Wallet Extensions

Password managers are not the only victims of DOM extension clickjacking. The most widely used crypto wallets — MetaMask, Phantom, TrustWallet — rely on the same DOM injection mechanism to display or sign transactions. Consequently, a well-placed overlay or an invisible iframe tricks the user into believing they are approving a legitimate transaction, while in reality they are authorizing a malicious transfer or exposing their seed phrase.

Direct implication: Unlike stolen credentials or cloned TOTP, these leaks concern immediate financial assets. Billions of dollars in liquid value depend on such extensions. Therefore, the DOM becomes not only a vector of identity compromise but also a monetary exfiltration channel.

Fallible Sandbox & Browser-in-the-Browser (BITB)

Browsers present their sandbox as an impregnable fortress. However, DOM extension clickjacking and Browser-in-the-Browser (BITB) attacks prove otherwise. A simple overlay and a fake authentication frame can deceive the user into believing they are interacting with Google, Microsoft, or their bank — when in reality they are handing over secrets to a fraudulent page. Even frame-ancestors directives and some CSP policies fail to prevent such interface illusions.

This is where sovereign technologies change the equation. With EviBITB (IRDR), Freemindtronic integrates into PassCypher HSM PGP a detection and destruction engine for malicious iframes, neutralizing BITB attempts in real time. Activable with a single click, it operates in manual, semi-automatic, or automatic mode, entirely serverless and database-free, ensuring instant defense (explanation · detailed guide).

The keystone remains the sandbox URL. Each identifier or cryptographic key is bound to a reference URL securely stored inside the encrypted HSM. When a page requests autofill, the active URL is compared to the reference. If it does not match, no data is injected. Consequently, even if an iframe evades detection, the sandbox URL blocks exfiltration attempts.

This dual-layer barrier also extends to desktop usage. Through secure NFC pairing between an Android NFC smartphone and the Freemindtronic application embedding PassCypher NFC HSM, users benefit from anti-BITB protection on desktop. Secrets remain encrypted inside the NFC HSM and are only decrypted in volatile memory (RAM) for a few milliseconds, just long enough for autofill — never persisting in the DOM.

Strategic Signals from DEF CON 33

In the electrified corridors of DEF CON 33, it’s not just badges blinking — it’s our assumptions. Between a lukewarm beer and a frantic CTF, conversations converge on a single point: the browser is no longer a trust zone. Consequently, DOM extension clickjacking is treated not as a bug class, but as a structural failure affecting password managers, passkeys, and crypto wallets alike.

• The DOM becomes a minefield: it no longer hosts “basic XSS” only; it now carries identity primitives — managers, passkeys, and wallets — making autofill hijack via Shadow DOM a first-order risk.
• The “phishing-resistant” promise falters: watching a passkey get phished live feels like seeing Neo stabbed by a script kiddie — dramatic, yet technically trivial once the interface is subverted.
• Industrial slowness: some vendors patch in 48 hours; others drown in committees and press releases. Meanwhile, millions remain exposed to browser extension security flaws and stealth overlays.
• Zero Trust, reinforced: any secret that even touches the DOM should be treated as already compromised — from credentials to TOTP to passkeys.
• Return of sovereign hardware: as cloud illusions crumble, eyes turn to Zero-DOM countermeasures operated offline: PassCypher NFC HSM, PassCypher HSM PGP, and SeedNFC for encrypted backup of crypto keys. Zero DOM, zero interface illusion.

Sovereign Countermeasures (Zero DOM)

Vendor patches may reassure in the short term, yet they do not resolve the core issue: the DOM remains a sieve. The only durable response is to remove secrets from its reach. This principle, known as Zero DOM, dictates that no sensitive data should reside in, transit through, or depend on the browser. In other words, DOM extension clickjacking is neutralized not by patchwork, but by architectural sovereignty.

In this paradigm, secrets (credentials, TOTP, passkeys, private keys) are preserved in offline hardware HSMs. Access is only possible via physical activation (NFC, HID, secure pairing) and leaves only an ephemeral footprint in RAM. This eliminates DOM exposure entirely.

Unlike cloud password managers or FIDO passkeys, these solutions do not apply reactive patches — they eliminate the attack surface by design. This is the essence of the sovereign-by-design approach: decentralized architecture, no central server, and no database to siphon.

PassCypher HSM PGP — Patented Zero-DOM Technology Since 2015

Long before the exposure of DOM Extension Clickjacking at DEF CON 33, Freemindtronic took another path. Since 2015, our R&D established a founding principle: never use the DOM to carry secrets. This Zero Trust doctrine gave birth to a patented Zero-DOM architecture in PassCypher, ensuring that credentials, TOTP/HOTP, passwords, and cryptographic keys remain confined in a hardware HSM — never injected into a manipulable environment.

🚀 A Unique Advance in Password Managers

• Native Zero DOM — no sensitive data ever touches the browser.
• Integrated HSM PGP — AES-256 CBC encryption + patented key segmentation.
• Sovereign Autonomy — no server, no database, no cloud dependency.

🛡️ Reinforced BITB Protection

Since 2020, PassCypher HSM PGP has included — even in its free version — the technology EviBITB.
This innovation neutralizes Browser-in-the-Browser (BITB) attacks in real time: destroying malicious iframes, detecting fraudulent overlays, and validating contexts serverlessly, database-free, and completely anonymously.
Learn how EviBITB works in detail.

⚡ Immediate Implementation

The user configures nothing: simply install the PassCypher HSM PGP extension from the
Chrome Web Store or Edge Add-ons, enable the BITB option, and enjoy Zero-DOM sovereign protection instantly — where competitors are still scrambling to react.

PassCypher NFC HSM — Sovereign Passwordless Manager

Software password managers fall into the trap of a simple iframe, but PassCypher NFC HSM follows a different path: it never lets your credentials and passwords transit through the DOM. The nano-HSM keeps them encrypted offline and only releases them for a fleeting instant in volatile memory — just long enough to authenticate.

User-side operation:

• Untouchable secrets — the NFC HSM encrypts and stores credentials so they never appear or leak.
• TOTP/HOTP — the PassCypher NFC HSM Android app or the PassCypher HSM PGP on desktop generates and displays them instantly on demand.
• Manual entry — the user enters a PIN or TOTP directly into the login field on a computer or Android NFC phone. The PassCypher app shows the code generated by the NFC HSM module. The same process applies to credentials, passkeys, and other secrets.
• Contactless autofill — the user simply presents the PassCypher NFC HSM module to a smartphone or computer, which executes autofill seamlessly, even when paired with PassCypher HSM PGP.
• Desktop autofill — with PassCypher HSM PGP on Windows or macOS, the user clicks the integrated login field button to auto-complete login and password, with optional auto-validation.
• Distributed anti-BITB — the NFC ↔ Android ↔ browser (Win/Mac/Linux) secure pairing triggers EviBITB to destroy malicious iframes in real time.
• HID BLE mode — a paired Bluetooth HID keyboard emulator injects credentials outside the DOM, blocking both DOM-based attacks and keyloggers.

PassCypher HSM PGP — Sovereign Anti-Phishing Key Management

In a world where traditional managers are looted by a simple phantom iframe, PassCypher HSM PGP refuses to bend.

Its rule? Zero server, zero database, zero DOM.

Your secrets — credentials, passwords, passkeys, SSH/PGP keys, TOTP/HOTP — live in AES-256 CBC PGP encrypted containers, protected by a patented segmented-key system engineered to withstand even the quantum era.

Why does it resist DEF CON 33-class attacks?

Because nothing ever transits through the DOM, no master password exists to be extracted, and crucially: containers stay encrypted at all times. The system decrypts them only in volatile RAM, for the brief instant required to assemble key segments. Once autofill completes, everything vanishes instantly — leaving no exploitable trace.

Key Features:

• Shielded autofill — one click is enough, but always via URL sandbox, never in cleartext inside the browser.
• Embedded EviBITB — destroys malicious iframes and overlays in real time, operable in manual, semi-automatic or fully automated mode, entirely serverless.
• Integrated crypto tools — generation and management of segmented AES-256 keys and PGP keys without external dependencies.
• Universal compatibility — works with any site via software + browser extension — no forced updates, no additional plugins.
• Sovereign architecture — no server, no database, no master password, fully anonymized — unattackable by design where cloud managers collapse.

SeedNFC + HID Bluetooth — Secure Wallet Injection

Browser wallet extensions thrive in the DOM — and attackers exploit that weakness. With SeedNFC HSM, the logic flips: the enclave never releases private keys or seed phrases. When users initialize or restore a wallet (web or desktop), the system performs input through a Bluetooth HID emulation — like a hardware keyboard — with no clipboard, no DOM, and no trace for private keys, public keys, or even hot wallet credentials.

Operational flow (anti-DOM, anti-clipboard):

• Custody — the SeedNFC HSM encrypts and stores the seed/private key (never exports it, never reveals it).
• Physical activation — the NFC HSM authorizes the operation when the user presents it contactlessly via the Freemindtronic app (Android NFC smartphone).
• HID BLE injection — the system types the seed (or required fragment/format) directly into the wallet input field, outside the DOM and outside the clipboard, resisting even software keyloggers.
• BITB protection — users can activate EviBITB (anti-BITB iframe destroyer) inside the app, which neutralizes overlays and malicious redirections during onboarding or recovery.
• Ephemerality — volatile RAM temporarily holds the data during HID input, then instantly erases it.

Typical use cases:

• Onboarding or recovery of wallets (MetaMask, Phantom, etc.) without ever exposing the private key to the browser or DOM. The HSM keeps the secret encrypted and decrypts it only in RAM, for the minimal time required.
• Sensitive operations on desktop (logical air-gap), with physical validation by the user: the user presents the NFC HSM module under an Android NFC smartphone to authorize the action, without keyboard interaction or DOM exposure.
• Secure multi-asset backup: an offline hardware HSM stores seed phrases, master keys, and private keys, allowing reuse without copying, exporting, or capturing. Users perform activation exclusively through physical, sovereign, and auditable means.

Exploitation Scenarios & Mitigation Paths

The revelations of DEF CON 33 are not the end of the game, but a warning. What follows may prove even more corrosive:

• AI-driven phishing + DOM hijack — Tomorrow, it will not be a garage-made phishing kit, but LLMs generating real-time DOM overlays, virtually indistinguishable from legitimate banking or cloud portals. These AI-powered clickjacking attacks will weaponize Shadow DOM credential theft at scale.
• Hybrid mobile tapjacking — The touchscreen becomes a minefield: stacked apps, invisible permissions, and background gestures hijacked to validate transactions or exfiltrate OTPs. This represents the evolution of tapjacking phishing into systemic mobile compromise.
• Post-quantum ready HSM — The next line of defense will not be a browser patch, but quantum-resistant HSMs capable of withstanding Shor’s or Grover’s algorithms. Solutions such as PassCypher HSM PGP and SeedNFC, already designed as Zero-DOM post-cloud sovereign anchors, embody this paradigm shift.

Strategic Synthesis

DOM extension clickjacking reveals a stark truth: browsers and extensions are not trust environments. Patches arrive in fragmented waves, user exposure reaches tens of millions, and regulatory frameworks remain in perpetual catch-up mode.
The only sovereign path? Strict software governance, combined with offline hardware safeguards outside the DOM (PassCypher NFC HSM / PassCypher HSM PGP), where secrets stay encrypted, offline, and untouchable by redressing.

The Sovereign Path:

• Strict governance of software and extensions
• Hardware-backed identity security (PassCypher NFC HSM / HSM PGP)
• Secrets encrypted, outside DOM, outside cloud, redress-proof