Chrome Extension Security Checklist for 2026

A poorly-secured Chrome extension can leak browsing data, expose API keys, or become a vector for account takeover. The good news: most security issues are caught by a short pre-publish checklist.

Pre-publish checklist

• No hardcoded API keys, tokens, or secrets in any source file.
• Content scripts use Shadow DOM for injected UI to prevent CSS-based clickjacking.
• All external API calls go through the service worker, not content scripts.
• `host_permissions` is scoped to the minimum domains required.
• No use of `eval`, `new Function`, or remote-loaded scripts.
• Content Security Policy in the manifest blocks remote code execution.
• User data stored in `chrome.storage.local` is encrypted if sensitive.

Reviewing AI-generated extensions

ManifestGo applies these defaults automatically. When you download the .zip, open the manifest and confirm the permissions match what you asked for — never ship an extension whose permissions you don't understand.

Content Security Policy fields you must set explicitly

• content_security_policy.extension_pages — controls what your popup/options pages can load; MV3's default already blocks inline scripts and remote code, but you should still set 'script-src 'self'' explicitly for clarity and future-proofing.
• content_security_policy.sandbox — a separate, looser policy for any sandboxed iframe pages you declare under sandbox.pages, used when you need eval() for a third-party library that can't run under the strict default policy.
• MV3 outright removed the ability to execute remotely hosted code in the extension's own pages, closing the most common MV2 malware vector.

Permission scoping specifics

• Use optional_permissions plus chrome.permissions.request() for features not every user needs — this keeps the initial install-time permission prompt minimal, which also reduces review scrutiny.
• Prefer 'activeTab' over persistent host_permissions whenever a feature only triggers from a user click (toolbar icon or context menu) — activeTab grants temporary access only to the current tab and only after user interaction.
• Never request <all_urls> if a finite list of domains covers your actual use case; reviewers manually check this against your stated single purpose.

Supply-chain risks unique to extensions

A compromised npm dependency bundled into your background.js has full access to every permission you've been granted — including cookies, browsing activity, and any host permissions. Pin dependency versions, run npm audit before every release, and avoid bundling analytics SDKs that phone home with more data than your privacy policy discloses; several real Web Store malware incidents originated from a legitimate extension being sold to a new owner who shipped a malicious update.

Manifest V3 removed attack surfaces worth knowing about

• Remote code execution via eval/new Function in extension pages — blocked by the mandatory CSP.
• webRequest blocking for network interception — largely replaced by declarativeNetRequest, which uses static, reviewable rule lists instead of arbitrary JS that can inspect and rewrite every request.
• Unlimited background page lifetime for silent, continuous data collection — replaced by the short-lived service worker model.

Incident response basics

1. If you suspect a compromised release, publish a patched version immediately and use chrome.runtime.requestUpdateCheck server-side signaling isn't available — instead, rely on Chrome's normal update cycle (hours) and email your user list if you have one.
2. Revoke any exposed API keys or OAuth client secrets server-side the moment a leak is discovered.
3. File for Web Store takedown of the malicious version if your developer account was itself compromised.

Baseline ManifestGo produces

Generated projects default to activeTab over broad host permissions, a strict CSP with no inline scripts, and no bundled third-party analytics — a safer starting point than most hand-rolled MV2-era boilerplate still circulating online.