Crypto Wallet Penetration Testing: What to Test

Updated October 2026 6 min read

Quick answer. A crypto wallet penetration test covers four areas: key generation and storage, signing flows, the backend and API, and the update and supply chain. Mobile, desktop and extension builds each add their own platform surface on top.

Watch: Crypto Wallet Penetration Testing: What to Test 1:42

Video transcript

A wallet decides what gets signed, and it is the last screen before an irreversible transaction. Here is what a serious pentest should check.

A wallet pentest covers four areas: key generation and storage, signing flows, the backend and API, and the supply chain that ships updates.

The questions stay the same, but the platform changes where risk sits: keystores and WebViews on mobile, Electron isolation on desktop, and permissions and messaging in extensions.

A wallet's worst failure is signing the wrong thing. What gets signed must match the screen byte for byte, and blind signing is a finding, not a default.

Signing clients get attacked directly. Guardian pentested the Electron desktop signer behind LayerZero's OneSig, and it returned 82 findings, including seven Highs.

Releases are attack surface too. In 2023, a phished npm account shipped malicious versions of Ledger's Connect Kit, with reported losses of six hundred thousand dollars or more.

Newer models relocate risk rather than removing it. Embedded wallets add the provider's backend, MPC adds share handling and recovery, and passkeys add WebAuthn libraries and signing policy.

Guardian's offchain department is led by Carlos Polop, creator of HackTricks. Every engagement runs two independent teams, and only human-verified findings reach the client.

Read the full guide for the checklist, or book an hour-long system review with a Guardian engineer at guardian.security.

A wallet generates the keys, decides what gets signed, and is the last screen before an irreversible transaction.

Crypto wallet penetration testing attacks that software the way a real adversary would, across the mobile, desktop and extension builds a team ships.

Here is what a serious engagement checks, platform by platform, with a checklist your engineers can act on first.

Key generation and storage

Everything else is downstream of the key: where it comes from, where it lives, and what can read it.

Entropy. Seed generation must use a cryptographically secure random source. A predictable generator makes every wallet it produced brute-forceable.
Hardware-backed storage. Android Keystore material never enters the app process and can be bound to the TEE or StrongBox. iOS Secure Enclave P-256 keys cannot be exported. The review checks that signing keys actually use them.
User presence. Keys should require recent authentication (setUserAuthenticationParameters on Android, flags such as .biometryAny on iOS), so a compromised process cannot sign alone.
Plaintext exposure. How long a decrypted seed lives in memory, and whether it lands in logs, crash dumps, telemetry, backups or the clipboard.
At rest. Vault encryption, the key-derivation function and its parameters, and whether secure hardware or only app logic enforces the passcode.

Signing flows and UI integrity

A wallet’s most dangerous failure is signing the wrong thing. The reviewer tries to break the link between what the user sees and what is signed.

What you see is what you sign. The payload sent to the signer must be byte for byte what the interface showed.
Readable signing. On EVM chains, EIP-712 typed data shows human-readable fields, with a domain separator binding the signature to a contract and chain.
No blind signing. Blind-signing an opaque hex blob is a finding, not a default.
Who can trigger a signature. Can a hostile site, deep link, QR code or injected frame start a request the user did not intend?
Transaction decoding. The wallet should decode calldata and approvals, and warn on unlimited allowances and unexpected delegatecalls.

More in wallet frontend security after Bybit.

Mobile, desktop and extension

The questions stay the same. The platform changes where the risk sits.

Mobile wallets

Mobile reviews follow the OWASP MASVS control groups, from storage and cryptography to platform interaction.

WebView bridges get close attention. Android’s addJavascriptInterface exposes a native object to every frame, including iframes, with no way to verify the caller’s origin.

Android’s guidance is to keep such bridges away from untrusted content, and to name the expected origin on message channels.

Desktop wallets

Many desktop wallets and signers are built on Electron, which publishes a 20-item security checklist.

The high-value items for a wallet: no Node.js integration for remote content, context isolation and sandboxing, a restrictive CSP, and validated IPC senders.

Signing clients get attacked directly. Guardian pentested the Electron desktop signer behind LayerZero’s OneSig, attacking the client itself rather than assuming the signer sees what they approve.

It returned 82 findings, including seven Highs.

Extension wallets

Under Manifest V3, the default CSP for extension pages is script-src 'self'; object-src 'self', and remotely hosted code is not allowed. A review confirms neither is worked around.

The reviewer maps permissions against real need, then tests whether an untrusted page can reach a privileged handler via the content script, background worker or popup.

Chrome’s guidance is to assume content-script messages might be crafted by an attacker, and that data sent to a content script might leak to the page.

And chrome.storage.local is exposed to content scripts by default, so keys do not belong there.

Backend and supply chain

Many wallets, and almost every embedded or wallet-as-a-service product, have a backend that authenticates users, holds or helps reconstruct key material, and exposes APIs.

It is tested as its own surface: authentication and recovery, session lifetime, access control, object-level checks, and the value-moving endpoints.

API keys get particular attention. A stolen key that is never scoped or revoked is worth whatever it can reach.

Updates and releases

A wallet is trusted continuously, so the way new code reaches users is attack surface.

The reviewer checks who can publish a release, whether that account and CI enforce MFA and provenance, and whether what ships matches the repository.

On December 24, 2024, a phishing attack gave an attacker a Cyberhaven employee’s Chrome Web Store credentials.

They were used to publish a malicious version of the company’s extension (24.10.4). Browsers that auto-updated between December 25 and December 26 received it.

In December 2023, a former Ledger employee’s npm account was phished and used to publish malicious versions of Ledger’s Connect Kit (1.1.5 to 1.1.7).

It drained funds from users of dApps that loaded the library until a fixed 1.1.8 shipped. Reported losses were roughly $600,000 to $680,000.

Embedded wallets, MPC and passkeys

Newer wallet models remove the seed phrase but relocate the risk rather than removing it.

Embedded and wallet-as-a-service. The provider’s backend, API and key-reconstruction path become part of your threat model.
MPC. Risk moves into share generation and storage, participant authentication, what a subset below threshold can force, and recovery after a node is compromised.
Passkeys and smart-contract wallets. Risk moves into the WebAuthn and EIP-712 libraries, the signing policy, and the recovery contracts.

Guardian has reviewed Ethena’s EthenaPay passkey smart wallet three times as it grew, including every facet and the WebAuthn and EIP-712 libraries underneath.

A crypto wallet pentest checklist

Run through this shortlist before an external engagement.

Seeds and keys use a secure random source and are never logged, cached or copied to the clipboard.
Signing keys are bound to secure hardware and require recent user authentication.
The signing screen decodes the real transaction, with EIP-712 where applicable and no silent blind signing.
No untrusted page, deep link or QR code can trigger a signature the user did not initiate.
Mobile: no addJavascriptInterface bridge is reachable from untrusted web content.
Mobile: message channels name an explicit origin, and sensitive screens block capture.
Desktop: Node integration off for remote content; context isolation and sandbox on.
Desktop: CSP set, IPC senders validated, Electron current, fuses locked.
Extension: permissions minimized, Manifest V3 CSP intact, no remotely hosted code.
Extension: untrusted-page messages cannot reach privileged handlers; no keys in storage.local.
Backend: value-moving actions are authorized server-side; API keys are scoped, expiring and revocable.
Releases: publishing and CI enforce MFA and provenance; the artifact is reproducible from the repository.
MPC, embedded or passkey wallets: share handling, recovery and signing policy are tested, not assumed safe.

How Guardian pentests wallets

Guardian’s offchain security department is led by Carlos Polop, creator of HackTricks and the PEASS privilege escalation suite.

Wallet work runs through its browser extension, web app, API and offchain automation pentests, and the SDK audit for wallet libraries.

For USDT0, Guardian reviewed the full client stack, web, desktop and API, for authentication, key handling and business-logic enforcement.

Every engagement runs two independent teams, and only human-verified findings reach the client.

Not sure what to scope first? A system review call is an hour with a Guardian engineer on what you run and who holds the keys that can move funds.

Comparing providers? See the best web3 pentesting firms and what a web3 pentest costs.

Frequently Asked Questions

What does a crypto wallet penetration test cover?

It covers key storage, whether the signed payload matches the screen, the backend and APIs, and the update and supply chain. Mobile adds platform storage and WebViews, desktop the Electron or native shell, and extensions their permissions and messaging.

Do you need the source code to pentest a wallet?

Source code is strongly recommended and, for a browser extension, effectively required. A store download or binary alone cannot confirm that every code path was reviewed, that keys never leave secure hardware, or that the signing screen matches the transaction.

Are MPC and smart contract wallets safer than a seed phrase?

They remove the seed phrase as a single point of failure, but add their own attack surface. MPC moves risk into share handling, authentication and recovery. Passkey and smart contract wallets move it into signing policy, recovery contracts and WebAuthn.

Sources

Pentest your wallet before someone else does

Guardian pentests wallet extensions, desktop signers, backends and SDKs, from key storage and signing flows to the supply chain that ships them, in a department led by HackTricks creator Carlos Polop.

Talk to Guardian Book a system review