DOM Extension Clickjacking — Risks, DEF CON 33 & Zero-DOM fixes

What is DOM-based extension clickjacking?

DOM-based extension clickjacking hijacks a browser extension (password manager or crypto wallet) by abusing the browser’s Document Object Model. A deceptive page chains invisible iframes, Shadow DOM and a malicious focus() call to trigger autofill into an invisible form. The extension “believes” it is interacting with a legitimate field and pours secrets there — credentials, TOTP/HOTP codes, passkeys, even private keys. Because these secrets touch the DOM, they can be exfiltrated silently.

How dangerous is it?

This vector is far from minor: it exploits the autofill logic itself and operates without user awareness. The attacker does not merely overlay an element; they force the extension to fill a fake form as if nothing were wrong, making exfiltration undetectable by superficial inspection.

Typical attack flow

1. Preparation — the malicious page embeds an iframe that is invisible and a Shadow DOM that masks the real context; inputs are rendered non-visible (opacity:0, pointer-events:none).
2. Bait — the victim clicks a benign element; redirections and a malicious focus() redirect the event to an attacker-controlled input.
3. Exfiltration — the extension believes it is interacting with a legitimate field and automatically injects credentials, TOTP, passkeys or private keys into the fake DOM; the data is immediately exfiltrated.

This mechanism spoofs visual cues, bypasses classic protections (X-Frame-Options, Content-Security-Policy, frame-ancestors) and turns autofill into an invisible data-exfiltration channel. Browser-in-the-Browser (BITB) overlays and Shadow DOM manipulation further increase the risk, making synced passkeys and credentials phishable.

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.

Vulnerable Password Managers & CVE disclosure (snapshot — 17 Sep 2025)

Updated: 17 September 2025

Following Marek Tóth’s demonstrations at DEF CON 33, multiple DOM-extension clickjacking issues were submitted for CVE assignment. Patching activity accelerated in August–September 2025, but vendor responses remain uneven. The table below summarises vendor status (credentials / TOTP / passkeys and patch status). For testing methodology and details, see the section “Correction Technologies” and vendor release notes linked in the table.

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 & Doctrinal Analysis

DOM extension clickjacking is a structural design flaw: secrets injected into a manipulable DOM can be hijacked unless the injection flow is architecturally separated from the browser.

What Current Fixes Do Not Address

• No vendor has rebuilt its injection engine.
• Fixes mostly limit activation (disable autofill, subdomain filters, detect some invisible elements) rather than change the injection model.

What a Structural Fix Would Require

• Remove dependency on the DOM for secret injection.
• Isolate the injection engine outside the browser (hardware or separate secure process).
• Use hardware authentication (NFC, PGP, secure enclave) and require explicit physical/user validation.
• Forbid interaction with invisible or encapsulated elements by design.

Typology of Fixes

Doctrinal Tests to Verify Patches

To check whether a vendor’s fix is structural, researchers can:

• Inject an invisible field (opacity:0) inside an iframe and verify injection behavior.
• Check whether extensions still inject secrets into encapsulated or non-visible inputs.
• Verify whether autofill actions are auditable or blocked when context mismatches occur.

There is currently no widely adopted industry standard (NIST/OWASP/ISO) governing extension injection logic, separation of UI and secret flows, or traceability of autofill actions.

Systemic Risks & Exploitation Vectors

DOM extension clickjacking is not an isolated bug but a systemic design flaw. When an extension’s injection flow is compromised, the impact goes well beyond a single leaked password: it can cascade through authentication layers and core infrastructure.

Critical scenarios

• Persistent access — cloned TOTP or recovered session tokens can re-register “trusted” devices and preserve access after resets.
• Passkey replay — an exfiltrated passkey can act as a reusable master token outside normal control boundaries.
• SSO compromise — leaked OAuth/SAML tokens from an enterprise extension can expose entire IT systems.
• Supply-chain exposure — weak or malicious extensions create a structural browser-level attack surface.
• Crypto-asset theft — wallet extensions that rely on DOM injection can leak seed phrases, private keys, or sign malicious transactions.

Regional Exposure & Linguistic Impact — Anglophone World

Strategic insight: the Anglophone sphere represents a large exposure surface; prioritize Zero-DOM, hardware-anchored mitigations in regional roadmaps. Sources: ICLS, Security.org, DataReportal.

Exposed Crypto Wallet Extensions

Crypto wallet extensions (MetaMask, Phantom, TrustWallet) often rely on DOM interactions; overlays or invisible iframes can trick users into signing malicious transactions or exposing seed phrases. See §Sovereign Countermeasures for hardware mitigations.

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

Browsers present their sandbox as a strong boundary — but DOM extension clickjacking and Browser-in-the-Browser (BITB) attacks show that UI-level illusions can still deceive users. A fake authentication frame or overlay can impersonate a trusted provider (Google, Microsoft, banks) and cause users to approve actions that release secrets or sign transactions. Standard directives such as frame-ancestors or some CSP rules do not necessarily block these interface forgeries.

Sandbox URL mechanism (technical): a robust Zero-DOM approach binds each credential or cryptographic reference to an expected URL (the “sandbox URL”) stored inside an encrypted HSM. Before any autofill or signing operation, the active page URL is compared to the HSM reference. If the URLs do not match, the secret is not released. This URL-level validation prevents exfiltration even when overlays or hidden frames evade visual detection.

Anti-iframe detection & mitigation (technical): real-time defenses inspect and neutralize suspicious iframe/overlay patterns (e.g., invisible elements, nested Shadow DOM, anomalous focus() sequences, unexpected pointer-events overrides). Detection heuristics include opacity, stacking context, focus redirections, and iframe ancestry checks; mitigation can remove or isolate the forged UI before any user interaction is processed.

For desktop flows, secure pairing between an Android NFC device and an HSM-enabled application allows secrets to be decrypted only in volatile RAM for a fraction of a second and injected outside the browser DOM, reducing persistence and exposure on the host system.

Phishable Passkeys — Overlay Attacks at DEF CON 33

At DEF CON 33, an independent demonstration showed that synced passkeys — often presented as “phishing-resistant” — can be silently exfiltrated using a simple overlay + redirect. Unlike DOM extension clickjacking, this vector requires no DOM injection: it abuses UI trust and browser-rendered frames to trick users and harvest synced credentials.

How the overlay attack works (summary)

• Overlay / redirect: a fake authentication frame or overlay is shown that mimics a platform login.
• Browser trust abused: the UI appears legitimate, so users approve actions or prompts that release synced passkeys.
• Synced export: once the attacker gains access to the password manager, synced passkeys and credentials can be exported and reused.

Synced vs device-bound — core difference

• Synced passkeys: stored and replicated via cloud/password-manager infrastructure — convenient but a single point of failure and phishable by UI-forgery attacks.
• Device-bound passkeys: stored in a device secure element (hardware) and never leave the device — not subject to cloud-sync export, therefore far more resistant to overlay phishing.

Proofs & evidence

• Allthenticate demonstration and living repository: yourpasskeyisweak.com.
• DEF CON technical slides / research: Passkeys Pwned — DEF CON 33 (PDF).
• Press coverage summarizing the demonstration: MENAFN / PR Newswire.

Phishable Passkeys @ DEF CON 33 — Attribution & Technical Note

Strategic Signals from DEF CON 33

DEF CON 33 crystallised a shift in assumptions about browser security. Key takeaways below are concise and action-oriented.

• Browsers are unreliable trust zones. The DOM should not be treated as a safe place for secrets.
• Synced passkeys & DOM-injected secrets are phishable. UI-forgery and overlay techniques can defeat cloud-synced credentials.
• Vendor responses vary; structural fixes are rare. Quick UI patches help, but few vendors have adopted architectural changes.
• Prioritise hardware Zero-DOM approaches. Offline, hardware-anchored flows reduce exposure and belong in security roadmaps.

Sovereign Countermeasures (Zero DOM)

Vendor patches can reduce immediate risk but do not remove the root cause: secrets flowing through the DOM. Zero DOM means secrets should never reside in, transit through, or depend on the browser. The durable defence is architectural — keep credentials, TOTP, passkeys and private keys inside offline hardware and only expose them briefly in volatile memory when explicitly activated.

In a Zero-DOM design, secrets are stored in offline HSMs and released only after an explicit physical action (NFC tap, HID pairing, local confirmation). Decryption happens in volatile RAM for the minimal time required to fill a field; nothing persists in the DOM or on disk.

This architecture removes the injection surface rather than patching it: no central server, no master password to extract, and no persistent cleartext inside the browser. Implementations should combine sandboxed URL checking, minimal ephemeral memory windows, and auditable activation logs to verify each autofill operation.

passcypher-hsm-pgp

PassCypher HSM PGP — Patented Zero-DOM Technology & Sovereign Anti-Phishing Key Management

Long before DOM Extension Clickjacking was publicly exposed at DEF CON 33, Freemindtronic adopted a different approach. Since 2015 our R&D has followed a simple founding principle: never use the DOM to carry secrets. That Zero-Trust doctrine produced the patented Zero-DOM architecture behind PassCypher HSM PGP, which keeps credentials, TOTP/HOTP, passkeys and cryptographic keys confined in hardware HSM containers — never injected into a manipulable browser environment.

A unique advance in password managers

• Native Zero-DOM — no sensitive data ever touches the browser.
• Integrated HSM-PGP — AES-256-CBC encrypted containers with patented segmented-key protection.
• Sovereign autonomy — no server, no central database, no cloud dependency.

Reinforced BITB protection (EviBITB)

Since 2020 PassCypher HSM PGP embeds EviBITB, a serverless engine that neutralizes Browser-in-the-Browser (BITB) attacks in real time by detecting and destroying malicious iframes and fraudulent overlays and validating UI context anonymously. EviBITB can operate manually, semi-automatically or fully automatically to drastically reduce BITB and invisible DOM-hijacking risk.

Why it resists DEF CON-style attacks

Nothing ever transits the DOM, there is no master password to extract, and containers remain encrypted at rest. Decryption occurs only in volatile RAM for the brief instant required to assemble key segments; after autofill the data is erased, leaving no exploitable trace.

Key features

• Shielded autofill — single-click autofill via sandboxed URL, never exposed in cleartext in the browser.
• Embedded EviBITB — real-time iframe/overlay neutralization (manual / semi / automatic), fully serverless.
• Integrated crypto tooling — segmented AES-256 key generation and PGP key management without external dependencies.
• Universal compatibility — works with any website via the extension; no additional plugins required.
• Sovereign architecture — zero server, zero central DB, zero DOM; designed to remain resilient where cloud managers fail.

Immediate implementation

No complex setup is required. Install the PassCypher HSM PGP extension from the Chrome Web Store or Edge Add-ons, enable the BITB option, and benefit instantly from Zero-DOM sovereign protection.

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.

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 DEF CON 33 revelations are a warning — threats will evolve beyond simple patches. Key near-term scenarios to watch:

• AI-driven clickjacking: LLMs and automation create realistic, real-time DOM overlays and Shadow-DOM traps at scale — making phishing + DOM hijack far more scalable and convincing.
• Hybrid mobile tapjacking: stacked UI elements, invisible gestures, and background app interactions enable large-scale mobile validation/exfiltration (OTP, transaction approvals).
• Post-quantum HSMs: long-term mitigation requires hardware anchors and quantum-resistant key management — move the security boundary into certified HSMs and out of the browser. See §Sovereign Countermeasures for architectural guidance.

Glossary

DOM (Document Object Model)

In-memory representation of a web page’s HTML/JS structure; allows scripts and extensions to access and modify page elements.

Shadow DOM

Encapsulated DOM subtree used to isolate web components; can hide elements from the rest of the document.

Clickjacking

UI redressing technique that tricks users into clicking hidden or overlaid elements.

DOM-Based Extension Clickjacking

Attack variant where a malicious page chains invisible iframes, Shadow DOM and focus() redirects to coerce an extension into injecting secrets into a fake form.

Autofill

Mechanism used by password managers and browser extensions to automatically populate credentials, OTPs or passkeys into web fields.

Passkey

WebAuthn authentication credential (public-key based). Passkeys are phishing-resistant when stored device-bound in a secure element; cloud-synced passkeys are more exposed.

WebAuthn / FIDO

Public-key authentication standard (FIDO2) for passwordless logins; security depends on storage model (synced vs device-bound).

TOTP / HOTP

One-time codes generated by time-based (TOTP) or counter-based (HOTP) algorithms for two-factor authentication.

HSM (Hardware Security Module)

Hardware device that securely generates, stores and uses cryptographic keys without exposing them in cleartext outside the enclave.

PGP (Pretty Good Privacy)

Hybrid encryption standard using public/private keys; here used to protect AES-256-CBC encrypted containers.

AES-256 CBC

Symmetric encryption algorithm (CBC mode) with 256-bit keys — used to encrypt secret containers.

Segmented keys

Key fragmentation approach: keys are split into segments to increase resistance and are assembled securely in ephemeral RAM.

Ephemeral RAM

Volatile memory where secrets are briefly decrypted for an autofill operation and immediately erased — no persistence to disk or DOM.

NFC (Near Field Communication)

Contactless technology used to physically activate an HSM and authorize local secret release.

HID-BLE (Bluetooth Low Energy HID)

BLE keyboard emulation mode to inject data directly into fields without using the DOM or clipboard.

Sandbox URL

Mechanism binding each secret to an expected URL stored inside the HSM; if the active URL does not match, autofill is blocked.

Browser-in-the-Browser (BITB)

Overlay attack that simulates a browser window inside an iframe — tricks users into interacting with a fake authentication frame.

EviBITB

Serverless anti-BITB engine that detects and destroys malicious iframes/overlays in real time and validates UI context anonymously.

SeedNFC

Hardware HSM solution for seed phrase / private key custody; performs out-of-DOM injection via HID/NFC.

Iframe

HTML frame embedding another page; invisible iframes (opacity:0, pointer-events:none) are commonly used in UI redressing attacks.

focus()

JavaScript call that sets focus on a field. Abused to redirect user events to attacker-controlled inputs.

Overlay

Visual layer (fake window/frame) that masks the real interface and deceives the user about the origin of an action.

Exfiltration

Unauthorized extraction of sensitive data from the target (credentials, TOTP, passkeys, private keys).

Phishable

Describes a mechanism (e.g., cloud-synced passkeys) that can be compromised by UI forgery or overlays — therefore vulnerable to phishing.

Content-Security-Policy (CSP)

Web policy controlling resource origins; useful but alone insufficient against advanced clickjacking variants.

X-Frame-Options / frame-ancestors

HTTP headers / CSP directives intended to limit iframe inclusion; can be bypassed in complex attack scenarios.

Keylogging

Malicious capture of keystrokes; mitigated by secure HID injection (no software keyboard or clipboard use).

Note: this glossary standardises terms used in the chronicle. For normative definitions and standards, consult OWASP, NIST and FIDO/WebAuthn specifications.