Browser Extension Stores Are Not Security Boundaries
Myth
Browser add-on stores inspect every published extension, making official marketplaces safe for administrative tools and crypto wallets.
Engineers often assume store listing equals security. We install developer add-ons, proxy switchers, and hardware wallet managers directly from Firefox Add-ons (AMO) or Chrome Web Store. The reasoning sounds logical. Mozilla and Google enforce automated scanning, require signed extension packages, and publish strict developer guidelines. If an extension sits in an official directory with thousands of active installs, users treat the publisher as verified. This trust is misplaced. Hundreds of users paste seed phrases, internal API tokens, and session cookies into extension popups without auditing source code or verifying publisher domain ownership.
Reality
Store linter scripts check for syntax compliance and static signature matches. They do not verify developer identity or runtime intent.
Recent disclosures exposed dozens of malicious wallet extensions hosted directly on Mozilla AMO. Attackers published clones of popular crypto tools like OKX, Rabby, and TronLink. The malicious extensions bypassed automated store ingestion checks by submitting clean initial codebases. Once published, the extensions updated remote configuration endpoints or executed obfuscated DOM scripts inside extension popups. When users opened the wallet interface, background content scripts captured keystrokes, extracted stored private keys, and posted raw payloads to attacker-controlled servers.
Automated marketplace linters flag known security anti-patterns like eval() calls. They cannot detect when a clean content script forwards form field values to a remote origin under the cover of legitimate analytics traffic.
Browser extensions operate under high-privilege access models. Permissions such as webRequest, storage, and broad host matches give background scripts direct access to network headers and DOM elements. Malicious add-ons abuse these permissions to bypass two-factor authentication by scraping session cookies during active login flows. Manifest V3 restricted some dynamic execution paths, but background service workers still hold enough access to compromise workstation security.
You can audit installed extensions on your local Linux workstation by querying Firefox profile state files directly with terminal tools.
# Extract installed Firefox extension IDs, names, and versions
jq -r '.addons[] | select(.type=="extension") | [.id, .version, .defaultLocale.name] | @tsv' \
~/.mozilla/firefox/*.default-release/extensions.json
# Unpack extension archive to inspect requested permissions
unzip -p ~/.mozilla/firefox/*.default-release/extensions/[email protected] manifest.json | jq '.permissions, .host_permissions'
How to protect
Do not rely on extension marketplace moderation to secure production environments. Treat every browser add-on as untrusted third-party code.
First, inspect requested extension permissions before allowing installation. Avoid extensions that demand global host permissions like <all_urls> or access to webRequestBlocking unless strictly necessary. If a simple utility requests full storage access across every website, block it.
Second, enforce enterprise policy controls to disable unapproved extension installations on organizational hardware. On Linux systems, define explicit allowlists inside Firefox enterprise policy files. This prevents users from adding unvetted store extensions.
# Create Firefox enterprise policy directory
sudo mkdir -p /etc/firefox/policies
# Enforce strict extension installation allowlist
cat << 'EOF' | sudo tee /etc/firefox/policies/policies.json
{
"policies": {
"ExtensionSettings": {
"*": {
"installation_mode": "blocked"
},
"[email protected]": {
"installation_mode": "allowed"
}
}
}
}
EOF
Third, verify public repository releases instead of searching marketplace directories. Clone the official repository, inspect `manifest.json`, and build XPI packages from source when handling sensitive production workflows.