As the number of onchain organizations continues to rise, so has the demand for Wallet-as-a-Service (WaaS) solutions. These solutions make it easy to embed secure, user-friendly wallets directly into web3 apps without requiring users to manage private keys themselves.
But while WaaS solutions deliver crucial infrastructure that supports trading, DeFi, and other capabilities, they also introduce new security risks that often go unnoticed. These risks aren’t just theoretical; they’re responsible for some of the most high-profile exploits in recent years. So, how can your organization ensure it addresses these risks before they become problems?
In this guide, we’ll break down seven commonly overlooked security risks facing WaaS solutions today. For each risk, we’ll highlight real-world incidents where these threats materialized, explain why they’re often missed, and showcase how WaaS architecture can be used to defend against them proactively.
1. Frontend compromise
A frontend compromise happens when malicious code is introduced into a production app. That code can alter transaction details, hijack user intent, or silently redirect funds. Because the app still looks and behaves normally, users have no reason to suspect anything’s wrong.
In late 2021, BadgerDAO was hit by a devastating $120 million exploit linked to a frontend compromise. After compromising cloud API keys, attackers injected malicious scripts into the platform. Users interacting with what looked like a trusted interface ended up signing transactions that drained their wallets.
Despite how dangerous attacks like these are, they’re often overlooked because many teams assume their deployments are secure, especially when using popular CI/CD tools. But without strong access controls, audit trails, or code integrity checks, even a small misstep, like a leaked credential, can lead to a full-scale breach.
To mitigate this threat, leading WaaS providers (like Turnkey) offer policy-based transaction gating to support fine-grained control over what actions are allowed, when, and by whom. For example, allowing swaps but requiring extra approval for withdrawals. They’ll also support multi-device workflows or enforce a clean separation between action initiation and final authorization. These safeguards help limit what a compromised frontend can do.
2. Malicious code on user machine
This risk highlights one of the most difficult challenges in wallet security: dealing with malicious code on the end user’s device. Whether it comes from a rogue browser extension or other malware, the effect is the same. Attackers gain visibility or control over sensitive actions and can redirect transactions, steal credentials, or approve transfers on the user’s behalf.
In 2022, Cyble Research and Intelligence Labs analyzed a fake MetaMask browser extension that quietly stole user seed phrases and private keys. Once installed, the malware could manipulate wallet interfaces and siphon off funds, all without triggering any alarms. The malicious extension mimicked the real MetaMask so closely that many users had no idea they were being targeted until it was too late.
The reason this risk is often underestimated is simple: most teams are focused on securing their infrastructure. They assume if the app is safe, the experience is safe, but user devices are an uncontrolled environment. A fully secure app can still be exploited if the device it runs on is compromised.
To truly address the risk of malicious code, you need a WaaS provider that enables you to build in separation between the system that proposes a transaction and the system that authorizes it. The ideal setup for high-value wallets is one where your backend or another trusted system can validate the transaction intent independently, and co-sign it – effectively requiring consensus before any action goes onchain.
This only works if your WaaS provider supports multi-approver workflows, custom signing policies, or multi-device authentication. These safeguards can help ensure that even if a user’s device is compromised, an attacker can’t approve critical actions without access to an independent second factor.
3. Man-in-the-Middle (MITM) attacks
MITM attacks occur when malicious parties intercept communications between an end user and the server. If the system relies on bearer tokens, session cookies, or standard transport-layer protections alone, there’s often little to stop an attacker from stealing credentials or altering requests. That’s because bearer tokens don’t verify who is using them; whoever holds the token can use it.
In 2021,several DeFi platforms experienced MITM attacks due to weak SSL configurations and inconsistent request validation. These exploits allowed attackers to intercept and modify communications between users and the platforms, often without triggering any immediate alarms. In some cases, credentials were stolen in transit. In others, transaction payloads were quietly altered before being submitted to the network.
This risk tends to be overlooked because HTTPS is widely viewed as a default security layer, but in crypto, where every signed action carries financial weight, relying on transport security alone is a dangerous shortcut.
The solution is to shift authentication from the network layer to the client itself. WaaS providers should require asymmetric signatures generated on the client side — not just a standard valid session — to authenticate requests. This way, even if an attacker intercepts the network traffic, they can't forge or reuse it since the message's authenticity is cryptographically locked in.
4. Transaction construction manipulation
Another common, yet often invisible, security risk surrounding WaaS solutions involves manipulating the transaction payload before it’s signed. One example is malicious DEX approvals, where users believe they’re granting permission for a simple token swap but are actually authorizing a transfer of their entire wallet balance. These types of exploits often stem from unclear UX or hidden payload changes between transaction construction and signing.
Because many developers assume any transaction passed to the signer is trustworthy, this risk often slips under the radar. If an attacker can inject or modify the payload at any point, whether through a compromised frontend, malicious dependency, or vulnerable relay, they can trick users into signing actions they never intended.
That’s why leading WaaS providers separate transaction construction, signing, and broadcasting into distinct steps. They also apply policy-based checks at the signing layer to validate that each transaction matches the expected intent. Rather than relying on rigid defaults, they enable developers to define exactly what a “valid” transaction looks like for their specific use case.
5. Supply chain attacks
Even if your app is secure and your infrastructure is hardened, you’re still exposed to the weakest link in your software supply chain. In December 2024, attackers compromised the solana/web3.js library, publishing two malicious versions that injected a backdoor to exfiltrate private keys. DApps that directly handled keys and updated within a 5-hour window were affected, while non-custodial wallets with secure enclave-based key storage (like Turnkey) remained safe. This incident underscores how a single compromised dependency can instantly put user funds at risk.
These risks are easy to overlook. Most teams audit their own code, but not every nested npm module. Protect yourself by choosing a WaaS provider that assumes the software supply chain can and will break.
Turnkey’s architecture mitigates these risks by isolating key operations from your app entirely and minimizing the dependencies that we use, in particular in secure enclaves, where we scrutinize every additional dependency and version bump. Wallets stay in secure enclaves, cryptographic operations can’t be hijacked by compromised libraries, and signing functions are independent of compromised SDKs or dependencies.
6. Key retrieval and KMS compromise
These commonly overlooked breaches happen when attackers gain access to a provider’s Key Management System (KMS) and extract or misuse private keys. Once the keys are compromised, the attacker can sign transactions as if they were the legitimate user, and there’s no way to recover the funds.
The very first large-scale Bitcoin hack, Mt. Gox, happened this way, with attackers exploiting compromised private keys and weak security practices to siphon off hundreds of thousands of bitcoins. The industry has come a long way since then, but private key compromises remain an issue.The Bybit exchange suffered the largest cryptocurrency heist to date, with $1.5 billion stolen after hackers exploited operational vulnerabilities and manipulated a routine transfer process, gaining access to private keys and draining funds from the platform.
This risk is often overlooked because teams assume any reputable KMS is secure by default, but not all KMS implementations are created equal. Without proper isolation, access controls, and verification mechanisms, even well-known systems can become single points of failure.
A security-conscious WaaS provider should offer protections that include:
- Storing private keys in hardware-backed secure enclaves to prevent direct access or extraction.
- Enforcing role-based access controls so only authorized systems or personnel can interact with key material.
- Running all sensitive operations, from key generation to policy evaluation, in secure environments — not just securing signing.
Turnkey stores keys within secure enclaves and uses attestation to prove what code is running where. Even in the event of a server breach, private keys cannot be extracted or misused because they never leave the protected enclave environment.
7. Spoofing
One of the most common attack vectors in crypto today is app spoofing. In these attacks, a malicious actor creates a fake version of a real DeFi or wallet app. The layout, branding, and user flow often look identical to the real thing, which makes it easy to trick users into signing harmful transactions.
In 2024, a malicious Android application impersonating "WalletConnect" was discovered on the Google Play Store. Although WalletConnect is a protocol and doesn’t offer a standalone app, attackers exploited the brand’s name and logo to build trust with unsuspecting users. Over roughly five months, the app tricked more than 150 users and facilitated the theft of approximately $70,000 in tokens by prompting users to connect wallets and approve fraudulent transactions.
Spoofing works because trust is visual. If a site/app looks right, most users won’t question it. Because many teams focus on protecting their official domain or keeping their brand consistent, they may overlook the risk of lookalike interfaces, especially when hosted on different URLs.
That’s why it's important to choose a WaaS provider that doesn’t simply rely on the frontend to confirm identity or intent. The most secure solutions use cryptographic signatures tied to trusted devices or identities rather than trusting the interface itself.
Turnkey uses client-side asymmetric cryptography to bind authorization to the user’s actual device. Even if an attacker spoofs the entire frontend, they can’t forge a valid approval because the request isn't coming from a trusted, pre-authorized source.
Turnkey’s security-first approach to WaaS
Turnkey is a WaaS provider built with a security-first philosophy. From day one, we’ve designed our architecture to anticipate the real-world threats facing onchain organizations — not just react to them after the fact. By embedding security into every layer of the stack, from secure enclave-backed key storage to client-side authentication and policy-based transaction controls, we help teams stay ahead of risks before they become problems.
Turnkey was founded by the team behind Coinbase Custody, the world’s largest crypto custodian, with over $100 billion in assets secured. That experience has shaped how we think about protecting sensitive infrastructure at scale, and why our platform meets the same enterprise-grade standards trusted by some of the biggest names in crypto.
As organizations grow and their needs become more complex, Turnkey’s flexible wallet architecture ensures they can scale across teams, networks, and use cases — without having to rethink or rebuild their security model. Whether you’re operating a lean DeFi startup or expanding a global onchain business, Turnkey gives you the confidence to move fast without compromising on security.
Ready to secure your onchain operations? Get started with Turnkey today.
Related articles
