Cracks in Wallet Iframe Security

Let’s be clear: many wallet iframes are a security disaster waiting to happen. With over five years in digital asset security (and some team members with a decade in the field), we’ve observed a vast security gap between traditional banking standards and today’s crypto applications—wallets, dapps, smart contracts, and more—that simply aren’t safe enough for storing people’s or businesses' funds. Putting aside the debate over security awareness and culture in teams supposedly building “the future of finance,” we need to address something immediately alarming: in the race to innovate, some wallet providers are cutting corners with risky iframe practices, putting active user funds at serious risk.

In the past 24 months, Dfns' security team has uncovered critical vulnerabilities in 3 different wallet services. That’s already way too much. These issues flag the need for stronger security standards in blockchain finance and infrastructure without further ado. At last week’s DeFi Security Summit in Bangkok, I highlighted one of these iframe wallet risks that we have seen in real world implementation. I presented a case study of a vulnerability we found in multiple Decentralized Applications. Each time we encountered a vulnerable implementation we reached out to the teams, and some have since fixed the problem, though not all. Stay careful.

A big part of the security challenge in web3 is how these findings are received; too often, we encounter defensiveness or downplaying of issues as “configuration details” that users should handle on their own. If software isn’t secure—especially financial software—it just isn’t secure, period. We can’t afford this lack of accountability, it only delays progress. When weak designs and practices are exploited, it sets the industry back for years and everyone suffers from it.

Watch my talk for the full technical breakdown and recommended methods to protect users against wallet iframe vulnerabilities.  

Embedded wallets gone wrong

_{To maintain confidentiality, we'll refer to the misconfigured exchange simply as the "exchange" and the vulnerable wallet iframe as the "wallet service."}

Embedded wallets come in various forms. Initially, they were mainly APIs integrated by developer teams responsible for building the user interface. Since 2022, however, new "wallet authentication" providers have emerged, offering iframes that give easy access to classic wallet connections (think: Rainbow Kit). Recently, some of these providers also added key management features. Many of these teams likely saw this addition as trivial, not realizing the complexities they were taking on. Key management is (very) hard, involving algorithms, cryptography, infrastructure, deployment schemes, corporate security processes, and application security minutia. Most wallet auth providers aren’t equipped to handle this level of key security.

As they started their journey working with less security-minded use cases (e.g. NFT gaming, social apps, and loyalty programs), they didn’t see security as a significant hurdle. But when that market took a big hit, many pivoted. Some shifted away from wallets to become blockchain providers, while others rebranded, hired security experts, and moved toward finance-adjacent fields like DeFi. However, dApp teams, beyond smart contract auditing, often lack the robust best practices found in traditional banking security. This got evidenced at this year’s *DeFi Security Summit* in Bangkok, where many speakers offered little depth in terms of comprehensive security and using existing and battle tested risk management frameworks. Today, we see these newer wallet providers aggressively marketing to DeFi teams on Farcaster, encouraging them to integrate their iframes. Eager for new users and liquidity, some of those teams take bets and buy into their narratives, sometimes unaware of the risks these new wallet iframes could introduce.

For instance, the exchange we reviewed allowed users to create wallets on its platform using just their email, bypassing traditional wallet connections and seed phrases. This streamlined experience is enabled by the wallet service’s iframe. When users would enter their email and a one-time code, the wallet service iframe would generate a wallet address and private key using Shamir’s Secret Sharing (SSS). The private key is split into multiple parts—one on the user’s device, and the rest on the wallet service’s backend. While this setup appears secure, we identified several critical vulnerabilities.

Private key extraction made simple

1. Locating token and key share storage: The process started by examining the wallet service’s storage model. It uses Shamir Secret Sharing (SSS) to split the private key into multiple shares: one in the browser’s local storage and the rest on the wallet service’s backend. By opening the JavaScript console and looking in local storage, I found the authorization token, which, in the vulnerable implementation is  critical as it enables access to perform a key refresh ceremony and so provides access to the necessary number of shares to reconstruct the wallet private key.
2. Simulating cache clearing to exploit a wallet recreation vulnerability: To test this, I deleted the local key share from the browser’s storage to simulate a cache-clear scenario. Refreshing the page prompted the wallet iframe to recreate the wallet automatically. Monitoring network traffic showed that the authorization token was sent to the wallet service backend, which then restored the key shares and regenerated the wallet. This process exposed a vulnerability—there was no additional user verification required.
3. Using the authorization token as a key proxy: Exploring the authorization token’s role in retrieving the private key, I realized that this token alone could reconstruct the private key. I wrote a simple script that only needed the authorization token to trigger the wallet’s key retrieval process. Running this script successfully rebuilt the private key outside of its original environment, proving that with just the token, an attacker could access the private key—a serious security risk.
4. Observing token exposure via cookies: The authorization token was sent from the wallet service to the exchange which used it as a cookie, making it accessible within the exchange’s infrastructure. This setup meant that logging tools like Datadog, AWS CloudWatch, and Sentry could capture these cookies, exposing them to anyone with access to these logs. With this exposure, the tokens—and thereby the private key—could be accessed, compromising the wallet’s non-custodial security entirely.

With the exchange holding access to the tokens needed for key retrieval, aside from the security risks, it inadvertently (or not) assumes a custodial role. This level of access requires treating these tokens as if they were the private keys themselves, which introduces serious operational and regulatory risks that conflict with the non-custodial security model initially intended and advertised.

Demonstrating the security vulnerability

To show how serious this vulnerability is, we ran a controlled test using a simple script. With just the authorization  token—and without needing anything from local storage—we managed to reconstruct the user’s private key and access the wallet. This means that if these tokens are compromised, an attacker could load the wallet on any device, drain funds, or make transactions. This example reveals a fundamental flaw in relying only on token-based security, especially in a decentralized finance ecosystem where the risks are high.

How MPC and WebAuthn prevent this

This case study explores a key question: How can we strengthen the non-custodial stance of wallets without sacrificing security? A promising solution combines multi-party computation (MPC) with secure authentication protocol, WebAuthn, for local authentication.

1. Removing the single point of failure: MPC-based solutions, like those used by Dfns, create multiple private key shares, or “partial keys”, so the key never exists in one place. The signature process is distributed across a network of distributed signers, each holding only part of the key. This setup ensures that a private key is never fully reconstructed, making it virtually impossible for a single point of attack to compromise the wallet, unlike SSS.
2. Introducing native two-factor authentication: WebAuthn, authored by the W3C, allows users to authenticate using private keys called passkeys stored in secure hardware, such as security keys or secure phone enclaves. The backend only needs the corresponding public key to authenticate a user. This setup ensures that neither the exchange nor the wallet provider has access to the private key. The passkey, under the user's exclusive control, adds a second layer of security, aligning with NIST recommendations for key management.
3. Decentralized network and local-only security: By combining WebAuthn and MPC, wallets can avoid using cookies or locally stored shares, reducing the risk of unauthorized access through token compromise. Only the end user, with their unique passkey, can access and authorize transactions, making both the exchange and wallet provider non-custodial.

It’s time to revisit the basics

This case study shows that when wallet creation is made easier by lowering security standards, users are put at risk, and some projects may lose their true non-custodial nature. We encourage dApp developers and wallet providers to prioritize security by extending their due diligence beyond just smart contracts and SSO compatibility to prevent unauthorized access. As the digital asset ecosystem grows, so do the threats—and it's up to us in the security engineering community to advocate for solutions that genuinely protect users in blockchain-based finance.