A cryptocurrency user decides to manage holdings across Monero, Bitcoin, and Litecoin. They discover that some wallet providers offer web versions accessible from any browser, promising convenience and no installation friction. The appeal is straightforward: open a URL, load a wallet, move funds. But that simplicity conceals a cascade of security exposures that do not exist in properly designed desktop and mobile applications. Browser wallets introduce attack surfaces that users rarely understand until after a loss occurs.

The distinction matters because cryptocurrency security depends not on convenience but on control. A self-custody wallet is only as secure as the environment executing it. Browser-based storage transforms that environment from a sandboxed application with system-level protections into a tab inside a program designed for openness, JavaScript flexibility, and dynamic content loading. The result is that attackers have more ways to intercept keys, malicious JavaScript can run without triggering application permissions, and the user’s recovery phrase can be exposed through mechanisms that desktop security models were built to prevent.

Why browser wallets are fundamentally different from application wallets

A desktop or mobile cryptocurrency wallet runs as a discrete application with its own process, memory isolation, and file permissions controlled by the operating system. When you launch Cake Wallet on macOS, Linux, iOS, or Android, the operating system enforces boundaries: the wallet can access the device’s secure storage (such as Keychain on macOS or Keystore on Android), but malware running in a different process cannot directly read that storage without elevated privileges. The wallet’s code is also static—downloaded once, verified, and executed from disk or memory in a predictable way.

A browser wallet operates inside a web browser, an application designed to fetch and execute code from the internet continuously. Every time you visit a web wallet, the browser downloads JavaScript, CSS, and assets from a server. That code then runs in the browser’s JavaScript engine with access to local storage, IndexedDB, cookies, and the DOM. The browser itself tries to isolate tabs and origins using the same-origin policy, but that isolation is fundamentally different from the process-level separation provided by an operating system. A compromised ad network, a man-in-the-middle attack on an unencrypted connection, a malicious browser extension, or a DNS hijack can inject code into the page before the wallet’s JavaScript even begins to load.

The attack surface expands further when considering the supply chain. A desktop wallet’s code can be reviewed on GitHub, built from source by the user or a trusted community, and verified with cryptographic signatures. A web wallet served from a domain is controlled by whoever operates that domain’s infrastructure. If the server is compromised, the attacker controls what code runs for every user. If the hosting provider is breached, the same outcome occurs. If a CA issues a fraudulent certificate or DNS is poisoned, users land on a fake version. None of these attacks require the user to make a mistake; the attack is transparent.

This is why Cake Wallet’s architecture remains deliberately application-based rather than web-based. The project maintains an open-source repository where every build can be audited, and users can compile from source if they choose. That transparency cannot exist in a web wallet; you cannot inspect the code running on your screen by checking GitHub if that code is generated or modified server-side before delivery.

Phishing, malware injection, and DNS attacks targeting web wallets

A user searching for a cryptocurrency wallet may accidentally visit a phishing domain. Legitimate wallet websites look like their counterparts: they have similar names, similar interfaces, and sometimes they even serve legitimate-looking pages. The difference—often a single letter or a different TLD—goes unnoticed. The phishing site then asks the user to enter a recovery phrase or private key, sometimes through a fake import screen, sometimes through a “recovery” flow that seems helpful but is actually data theft.

Browser wallets make this attack more dangerous because the line between “legitimate website” and “fake website” is blurred. A user might reasonably believe that accessing a wallet through a bookmarked URL or a Google search result is safe. They do not expect the website to be malicious at that moment. A native application, by contrast, must be downloaded from a clearly identified source—the Apple App Store, Google Play, F-Droid, or GitHub. Those channels have their own security models, but they create a friction point where an attacker cannot simply register a domain and fool users into thinking it is the official application.

Man-in-the-middle attacks on unencrypted or poorly encrypted connections can also inject malicious code. If a browser wallet is served over HTTP or if the certificate is invalid, an attacker on the network (in a coffee shop, at an airport, or through ISP-level compromise) can intercept the connection and serve malicious JavaScript. The user’s browser will execute it just as if it came from the legitimate server. Even with HTTPS, certificate pinning (which is more common in native applications) can be circumvented in a browser because the browser’s certificate store is global and the attacker may have obtained a valid certificate from a compromised or malicious CA.

DNS attacks operate similarly. If an attacker controls DNS for the user’s network segment, they can redirect wallet.example.com to a server under their control. The browser will still load the page, possibly over HTTPS with a certificate the attacker can generate or obtain, and the user will have no reliable way to know they are on the wrong site. Mobile and desktop applications can implement certificate pinning—hardcoding the expected certificate of the legitimate server—which prevents this attack. Browser-based wallet providers cannot implement pinning as effectively because the browser itself controls certificate validation.

Local storage, IndexedDB, and the recovery phrase exposure problem

Every browser wallet must store the user’s recovery phrase or private key somewhere. It cannot live only in RAM because the user would lose access on page refresh. So wallets use browser local storage mechanisms: localStorage, IndexedDB, or cookies. These are files on the user’s disk, encrypted or unencrypted, that the browser manages.

The security of this approach depends entirely on how well the browser isolates that storage from other JavaScript contexts and from the operating system. A malicious browser extension can read IndexedDB entries for any site it is granted permission to access. A compromised ad network injected into a page can access localStorage through the same origin. If the device is infected with malware that runs at the OS level, extracting those files is trivial. Worse, the user has no notification that the key has been accessed. Unlike a hardware wallet or a desktop application where you might see an unlock dialog or a permission prompt, browser storage can be read silently.

On mobile devices, this problem is worse. A browser on iOS or Android shares a common data store for all tabs and extensions. If an app on the device is compromised, it may be able to read browser-stored data depending on OS version and sandbox configuration. Android’s sandboxing has improved in recent versions, but the principle remains: data stored in a browser is less protected than data stored in a dedicated application with hardware-backed encryption.

This is why Cake Wallet uses device-level secure storage. On iOS, private keys are encrypted using Apple’s Secure Enclave, a dedicated processor that never exposes unencrypted keys to the main CPU. On Android, keys are stored in the Android Keystore, which also provides hardware-backed encryption on compatible devices. A browser wallet cannot access these secure storage mechanisms; it is limited to the browser’s own storage APIs, which lack this protection.

The custodial risk when browser wallets fail or disappear

Browser wallet services are maintained by companies or projects. If the service shuts down, changes its terms, suffers a security breach, or is compromised by a government order, users may lose access to their funds. Some web wallets are explicitly non-custodial (the server never holds the private keys), but the user still depends on the provider’s infrastructure to access their wallet. If the domain is taken down, seized, or goes offline, the user’s only recourse is a local backup of their recovery phrase.

This creates a dependency that self-hosted desktop and mobile wallets eliminate. Cake Wallet stores nothing server-side for the user. The application can communicate with blockchain nodes and price data services, but it does not require a specific company’s infrastructure to function. If Cake Labs ceased operations tomorrow, every existing Cake Wallet installation would continue to work because it connects to public Monero and Bitcoin nodes and can recover funds using the recovery phrase alone. A browser wallet user has no such guarantee because their access depends on whether the service continues to operate the domain and maintain the infrastructure.

Regulatory enforcement can also affect browser wallet availability. Government agencies have requested that wallet providers implement compliance measures, block users from certain jurisdictions, or restrict access. A browser wallet, being server-controlled, can be instantly modified to comply. A desktop or mobile application cannot be modified remotely; updates require the user to download and install a new version. This creates a lag that gives users time to migrate funds if they disagree with policy changes. A web wallet can be changed in real time without user consent.

Open-source verification and the transparency advantage

One of the strongest arguments for Cake Wallet’s application-based approach is the ability to audit the code. The GitHub repository contains the full source code, build configurations, and release history. A security researcher, cryptocurrency enthusiast, or developer can review exactly what the wallet does with private keys, how it handles network communication, and what permissions it requests.

This transparency is incompatible with web wallets in practice. Even if a browser wallet provider publishes source code, the code running on their server may be different from what is published. Monitoring tools like certificate transparency logs or web archive snapshots can detect changes, but they cannot prove what code is executing at any moment. A server can serve different JavaScript to different users, perform A/B testing with different security models, or rotate changes frequently. The user has no way to verify that what they see on the screen matches what was reviewed by auditors.

Desktop and mobile applications have a different verification model. A privacy wallet like Cake Wallet can be built reproducibly, meaning that multiple independent parties can compile the source code and produce byte-for-byte identical binaries. If the published binary does not match the reconstructed version, the discrepancy is visible. This is not a guarantee against supply chain attacks (the signing key could be compromised), but it is a level of verification that web wallets fundamentally cannot achieve because the server can always serve different code.

Hardware wallet integration and the role of secure isolation

For users managing larger amounts of cryptocurrency, hardware wallets provide an additional layer of isolation. Ledger and Trezor devices sign transactions without exposing private keys to the computer or phone. A browser wallet cannot integrate with a hardware wallet as effectively as a native application. The browser has limited access to USB devices or Bluetooth connections, and any JavaScript on the page could theoretically request hardware wallet access. An application can establish a secure channel to a hardware wallet, verify its firmware, and validate that the device is displaying the correct transaction details before signing.

Bitcoin’s protocol specifications, including standards like BIP-352 for Silent Payments, define how wallets should construct transactions. Hardware wallet integrations depend on the application layer to prepare transaction details correctly and the hardware to validate them. A browser wallet’s integration with hardware is indirect and less controllable; the browser’s WebUSB or WebBluetooth APIs add a layer of indirection that application-based wallets can bypass.

This is why Cake Wallet’s support for Ledger and Trezor is more reliable than browser-based alternatives. The application has direct control over how the device is initialized, how transaction details are presented for signing, and how the signature is received and broadcast. A browser wallet must work through the browser’s hardware APIs, which are designed for general web access and lack the tight integration that cryptocurrency security requires.

Network-level privacy and the illusion of browser-based anonymity

Some browser wallets market Tor support or claim to offer network-level privacy through the browser. This is misleading because the browser is already a poor vector for privacy-sensitive operations. Tor is useful for hiding a user’s IP address, but it cannot hide browser fingerprinting, timing analysis, or the fact that a user is accessing a blockchain at all. A browser wallet using Tor still reveals that the user is connecting to a cryptocurrency service, whereas a dedicated application with built-in privacy features can handle network communication more carefully.

The Electronic Frontier Foundation has documented how browser fingerprinting allows websites to identify users even with Tor or VPN enabled. A wallet stored in a browser is subject to this fingerprinting. An application like Cake Wallet, which can be configured to route all traffic through Tor or a custom node, provides finer-grained control over what metadata is revealed.

Moreover, browser wallets often make requests to external services—price data, node lists, balance information—that leak user intent. An application can batch requests, use privacy-respecting nodes, and control its communication patterns more tightly. A browser’s normal behavior is to load resources from many domains, which makes it harder to reason about what information is leaked and to whom.

Best practices for secure self-custody without web wallets

Users seeking a secure, self-custody experience should prioritize native applications available on iOS, Android, macOS, and Linux. Cake Wallet exemplifies this approach: it is free, open-source, non-custodial, and transparent about its operations. When evaluating any wallet, verify the download source (official app stores or GitHub releases with cryptographic signatures), review the permissions requested, and test with a small amount before entrusting larger balances.

Recovery phrase storage is critical. Write the phrase on paper or use a metal backup device, store it offline in a secure location, and never photograph it or store it in a cloud service. A recovery phrase should be treated as equivalent to a password that can recover all funds; it should be created once, stored securely, and retrieved only when necessary.

For amounts that would cause significant loss if stolen, consider a hardware wallet. The cost of a Ledger or Trezor device is negligible compared to the security benefit. The device stores the private key and can sign transactions without exposing the key to your computer or phone. Monero’s official documentation and Litecoin’s specifications describe how privacy features work at the protocol level, providing a foundation for understanding what wallet features actually protect.

Avoid any wallet that requires entering a recovery phrase into a website, even if that website is the official provider. Legitimate providers will never ask for this information. If you must migrate from one wallet to another, create the new wallet first, verify its receiving address independently, send a small test amount, and only then consolidate larger balances. Never enter a recovery phrase into a browser.