Browser Extension Pentest Guide for Crypto Wallets

By the Guardian team Updated November 2026 6 min read

Quick answer. Review six areas from source: manifest and permissions, content-script isolation, message passing, key storage, the signing UI, and the publishing pipeline. Then attack it as a hostile website would, and as a malicious update would.

Watch: Browser Extension Pentest Guide for Crypto Wallets 1:42

Video transcript

A wallet extension holds keys and runs beside every page you open. It faces two attackers: hostile websites and malicious updates.

In December 2025, a malicious Trust Wallet extension went live. Trust Wallet says about 8.5 million dollars in assets were affected.

Review six areas from source: manifest, content scripts, messaging, key storage, signing UI and publishing pipeline. Then test it against both attackers.

Treat the manifest as an attacker's budget. An XSS bug on an allowed dapp domain lets attackers message the background script directly.

Isolation protects variables, not inputs. Chrome says to assume content script messages might be crafted by an attacker. Never send keys to a content script.

Chrome exposes storage dot local to content scripts by default, so keep only the encrypted vault there. Storage dot session stays in memory.

WalletProbe, a 2025 study of 39 browser wallet extensions, reports all could be abused to steal assets. Many could miss approvals or hide fields, and few caught every known phishing address.

Trust Wallet says leaked GitHub secrets gave an attacker store API access. Harden the pipeline with two-step verification, verified uploads, an isolated signing key and store monitoring.

Guardian's browser extension pentest works from both directions. It sits in Guardian's offchain team, led by HackTricks creator Carlos Polop.

Read the full guide, or send Guardian your store listing and repository to get scoped.

A wallet extension holds keys, runs beside every page its user opens, and shows the last screen before a signature. It faces two attackers: hostile websites and malicious updates.

On December 24, 2025, a malicious Trust Wallet extension, version 2.68, went live on the Chrome Web Store. Trust Wallet says 2,520 wallet addresses were drained, with about $8.5 million in assets affected.

This guide sets out how to pentest a wallet extension against both. For mobile and desktop wallets, see our crypto wallet pentesting guide.

The Wallet Extension Attack Surface

Map the components first. Each one trusts something different.

Component	What it trusts	What the tester asks
Manifest	Permissions, host access, CSP	How far could a malicious version reach?
Content script	The page's DOM	What can a hostile page make it do?
Service worker	Messages from scripts and pages	Which privileged handlers can a page reach?
Popup and extension pages	The extension's own origin	Can a page frame, spoof or fingerprint them?
Storage and memory	Extension contexts	What is readable while the wallet is unlocked?
Store listing	Publisher accounts and keys	Who can ship an update, and how?

Chrome's security guidance sets the baseline. HackTricks, the free wiki created by Guardian's offchain lead Carlos Polop, adds a browser extension pentesting methodology.

Manifest, Permissions and CSP

Read the manifest as an attacker's budget. Chrome's guidance is to minimize permissions "by only registering APIs and websites they depend on."

Permissions: match each permission and host permission to the feature that needs it.
CSP: Manifest V3 pages default to script-src 'self'; object-src 'self'; and cannot add script sources.
Sandbox pages: their CSP is "much more lenient," per Chrome. Check what runs there.
externally_connectable: with no entry, other extensions can connect but web pages cannot. Each listed origin can.
web_accessible_resources: none by default, since exposed files let sites fingerprint the extension.

The allowed origins deserve the most attention. HackTricks warns that an XSS bug or takeover on an allowed page lets an attacker message the background script directly.

That skips the content script, so a wallet's own dapp domains join its attack surface. See how to protect those domains.

Framable extension pages need a clickjacking test. HackTricks describes a fixed MetaMask case where a framable phishing-warning page could trick users into whitelisting a phishing site.

Content Scripts and Messaging

Chrome runs content scripts in an "isolated world." They share the page's DOM but not its JavaScript variables. Firefox calls its version Xray vision.

Isolation protects variables, not inputs. Chrome warns that hostile pages may manipulate the DOM that content scripts rely on, and puts sensitive work in the service worker.

Code injected into the page's main world loses even that. The page's CSP applies to it, and MDN warns that a hostile page "can redefine objects you interact with."

Message passing

Chrome's rule is blunt: "Assume that messages from a content script might have been crafted by an attacker." Test every route from page to content script to service worker:

List every onMessage, onMessageExternal and onConnect handler, and what each can do.
Check that external handlers validate the sender against a trusted list.
Send malformed, replayed and out-of-order messages to each handler.
Confirm no handler sends keys or seeds to a content script. Chrome says such data "might leak."
Check that a page cannot open a signing or connection request on its own.
Check that each site permission is bound to the origin that asked for it.

Key Storage and Signing

Find every place key material lives: at rest, in memory, and in transit between contexts.

storage.local: exposed to content scripts by default, per Chrome. Store only the encrypted vault.
storage.session: held in memory, never written to disk, and hidden from content scripts by default.
Access levels: setAccessLevel can limit a storage area to trusted extension contexts.
The vault: its encryption, key-derivation parameters and unlock timeout.
Memory: HackTricks shows how to snapshot the popup's heap and search it for secrets.
Clipboard: seeds and passwords should not stay on it.

The browser can leak secrets too. Under CVE-2022-32969, the "Demonic" issue, MetaMask before 10.11.3 could expose a recovery phrase typed into an input field.

Firefox and Chromium saved such fields to disk to restore sessions.

What is shown is what is signed

WalletProbe, a 2025 academic study, tested 39 widely used browser wallet extensions: 34 wallets and five transaction checkers. Its authors report that all of them could be abused to steal assets.

12 still supported eth_sign without warnings, so users saw only a hex string.
29 could miss an approval, such as one made through a less common approval function.
33 showed non-compliant data without a warning, or hid fields such as sender and chain ID.

The authors say 26 issues had been patched when they wrote. Test each class against your build: decode every approval, refuse eth_sign, and show every field that moves funds.

UI Spoofing and Phishing Resistance

A page can draw anything inside its own window, including a copy of your approval prompt. Real prompts belong where the page cannot draw.

Open every approval in an extension window, never in UI the page renders.
Try to frame each web-accessible page and overlay it to steal a click.
Show the requesting origin on every prompt, in a form the page cannot set.
Check how addresses, ENS names and token names render, including lookalikes.
Feed known phishing addresses and domains, and confirm a warning appears.

That last test often fails. In WalletProbe's tests, only three of the ten extensions that flag risky addresses caught every known phishing address in its set.

Securing the Build and Publish Pipeline

Trust Wallet says its developer GitHub secrets were exposed in Sha1-Hulud, a supply chain incident spread through compromised npm packages.

The attacker obtained full Chrome Web Store API access through the leaked key. Version 2.68 was published "outside of our standard release process," bypassing internal review and approval.

So the pipeline is in scope. Test and harden it:

Chrome Web Store requires 2-Step Verification on every developer account; Chrome advises security keys.
Give each publisher member only the role it needs.
Opt in to verified CRX uploads, so every update must be signed with your key.
Keep that signing key away from the CI secrets that hold store credentials.
Scope, rotate and monitor store API credentials like production keys.
Use deferred publishing and partial rollouts to limit a bad release.
Build reproducibly. Mozilla reviewers rebuild bundled add-ons from source: "There must be no differences."
Watch the store for versions you did not ship, and diff each against the repository.

Chrome says verified uploads "can prevent malicious updates if your developer account is compromised."

How Guardian Tests Extensions

Guardian's browser extension pentest works from both directions: what a hostile website can pull out, and what a compromised update could do.

It covers permissions and manifest, content scripts, internal messaging, key and session storage, signing flows and the supply chain.

Source code is effectively required, since a store download alone cannot confirm that every code path was reviewed. Send the store listing and the repository to get scoped.

The work sits in Guardian's offchain security department, led by Carlos Polop, creator of HackTricks and the PEASS privilege escalation suite.

See how it fits with audits on security for onchain teams.

Frequently Asked Questions

What does a browser extension pentest cover?

The manifest and permissions, content scripts, message handlers, key and session storage, signing flows, and the build and publishing pipeline. Guardian treats source code as effectively required.

Where should a wallet extension store keys?

In an encrypted vault, decrypted only in trusted extension contexts. Chrome exposes storage.local to content scripts by default, while storage.session stays in memory. Never send secrets to a content script.

How was the Trust Wallet extension compromised?

Trust Wallet says GitHub secrets exposed in the Sha1-Hulud attack gave an attacker a Chrome Web Store API key. Version 2.68 was then published outside its standard release process.

Is Manifest V3 enough to secure a wallet extension?

No. It bans remotely hosted code and sets a strict default CSP. It does not validate your messages, protect stored keys or stop UI spoofing.

Sources

Pentest your wallet extension before it ships

Guardian tests your extension against hostile websites and malicious updates, from the manifest and message handlers to key storage and the store pipeline.

Talk to Guardian Explore security for onchain teams