Chrome Extension Security Checklist: 15 Manifest V3 Best Practices (2026)

Q: What permissions should I avoid in Manifest V3?

Avoid broad host permissions like when specific patterns work. Avoid scripting permissions that allow cross-origin injection. Use optional_permissions so users grant access only when they take a specific action inside the extension.

TL;DR

15 Manifest V3 security requirements for Chrome extensions: minimize permissions, replace remote code with bundled scripts, isolate content script data, validate every runtime.onMessage sender, and set a strict CSP. Five items are critical before launch; the rest prevent Web Store removal.

Chrome extensions are among the most permission-rich software users install. A single extension approved to run on "all sites" can read bank account pages, capture form data, and intercept credentials. Chrome Web Store processed over 2.5 million extension policy actions in 2024, mostly for permission abuse and data exfiltration. This checklist covers every Manifest V3 security requirement, ordered by how fast a violation will get your extension delisted or exploited.

Critical: Fix Before Launch (5 Items)

Request minimum permissionsAvoid broad permissions like <all_urls> when specific host patterns work. Chrome Web Store reviewers flag overly broad permissions as a rejection reason.

Use Manifest V3MV2 extensions face forced removal. Service workers replace persistent background pages; declarativeNetRequest replaces blocking webRequest. Start on V3 or migrate now.

Never execute remote codeFetching JavaScript from an external server and eval-ing it is blocked by MV3 CSP and is a Web Store policy violation. All logic must be bundled at package time.

Avoid eval() and innerHTML with external dataEven with bundled code, eval() and innerHTML with DOM-sourced content introduce XSS. Use textContent for display and DOMParser for structured parsing.

Sanitize all data received from content scriptsContent scripts touch the host page DOM, which is untrusted. Never pass raw DOM strings to background scripts and execute them without sanitizing.

Permission Management (4 Items)

Use optional_permissions for runtime accessRequest host or API permissions only when the user performs an action that requires them. Users grant narrower access, and your install-time permission list stays short.

Explain every permission in your listingWeb Store reviewers and users read permission explanations. If you request 'tabs', explain why. Missing justification is a common rejection reason for sensitive permissions.

Scope host_permissions to specific patternsReplace <all_urls> with patterns like https://*.example.com/* wherever possible. Pattern-specific permissions show smaller warnings to users during install.

Audit permissions on every updateEach release, run through your manifest.json and remove permissions your code no longer uses. Accumulating dead permissions increases your attack surface and review risk.

Code Security (4 Items)

Set a strict Content Security PolicyIn manifest.json, set extension_pages CSP to script-src 'self'; object-src 'none'. This blocks inline scripts and remote script loading in your popup and options pages.

Validate all runtime.onMessage sendersAlways check sender.id === chrome.runtime.id before acting on a message. External sites can send messages to your extension if you expose a handler without a sender check.

Use declarativeNetRequest instead of webRequestBlocking webRequest is removed in MV3 for most cases. Use declarativeNetRequest with static or dynamic rulesets. This is also more privacy-preserving because your extension never sees request data.

Avoid persistent background pagesMV3 service workers terminate after a short idle period. Design for this: use chrome.storage for state, register alarms for recurring tasks, and never hold open connections that assume the background is always alive.

Data Handling (4 Items)

Validate message format and originCheck both sender.id (must match your extension) and the structure of the message payload. Reject anything that doesn't match the expected schema before processing.

Encrypt sensitive data before storingchrome.storage.local is not encrypted on disk. If you store tokens, credentials, or PII, encrypt them with the Web Crypto API before writing and decrypt after reading.

Clear data on uninstallRegister a chrome.runtime.onInstalled listener and use chrome.storage.local.clear() in your uninstall flow. Leaving user data behind is a privacy policy violation in most jurisdictions.

Do not exfiltrate browsing dataContent scripts can read page content. Sending that content to your server without explicit user consent violates Web Store policy and most privacy laws. Log only what you need for core functionality.

Privacy and Web Store Compliance (3 Items)

Publish a privacy policyRequired for any extension that requests sensitive permissions (cookies, history, tabs, webNavigation) or handles user data. Link it in your Web Store listing.

Minimize data collectionCollect only what the core feature requires. If your extension analyzes page text locally, don't send it to your server. Local-only processing is both more private and more trustworthy.

Describe all functionality in the listingHidden functionality (features not described in the listing) is an automatic policy violation. If a future update adds data collection, update the listing description before publishing the update.

Manifest V3: What Actually Changed for Security

Manifest V3, required for new extensions since June 2023 and enforced for existing ones in 2025, made several security-relevant changes.

Service workers instead of background pages. Persistent background pages could hold long-running connections and accumulate state indefinitely. Service workers terminate after roughly 30 seconds of inactivity and restart on demand. This limits what a compromised background script can do between activations.

declarativeNetRequest instead of blocking webRequest. Under MV2, an extension with webRequest could intercept, read, and modify every HTTP request the browser made. Under MV3, request modification goes through rule-based declarativeNetRequest, which the browser evaluates without exposing raw request data to extension code. This removes a class of credential-harvesting extensions.

Remote code execution blocked. MV3 extensions cannot fetch JavaScript from a remote server and run it. All logic must be in the extension package that Chrome reviews. This closes the most common malware distribution vector: an extension that looks clean during review but downloads malicious code after install.

Extensions that still use Manifest V2 will be disabled in Chrome in 2025. If you're shipping a V2 extension, migration is not optional.

Content Script Isolation in Practice

Content scripts run in an "isolated world": they share the page DOM but not the JavaScript globals. A page cannot read your extension's variables, and your extension cannot directly access a page's JavaScript objects.

What this does NOT protect you from:

DOM data is still untrusted. A malicious page can write arbitrary strings to DOM nodes your content script reads.
Message passing is not authenticated by default. Any site can send a message to your extension using window.postMessage or chrome.runtime.sendMessage if you listen without checking the sender.

Validate sender before acting on a message

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  // Only accept messages from our own extension
  if (sender.id !== chrome.runtime.id) {
    return false;
  }
  // Validate message structure
  if (typeof message.action !== 'string') {
    return false;
  }
  // Now safe to process
  handleMessage(message, sendResponse);
  return true; // Keep channel open for async response
});

Use TypeScript with strict types for your message payloads. Narrowing the union of valid message shapes at compile time catches a class of injection bugs before you ship them.

Why does Chrome require Manifest V3?

Manifest V3 improves security by replacing persistent background pages with short-lived service workers, blocking remote code execution, and requiring declarativeNetRequest instead of blocking webRequest. These changes shrink the attack surface significantly, particularly against extensions that download and run malicious code after passing the initial review.

What permissions should I avoid in Manifest V3?

Avoid broad host permissions like <all_urls> when specific patterns work. Avoid keeping webRequest in blocking mode (it is restricted in MV3). Use optional_permissions so users grant access only when they take a specific action inside the extension rather than at install time.

Can my extension be removed for security issues?

Yes. Chrome Web Store removes extensions with security vulnerabilities, excessive permissions, or policy violations. MV2 extensions face forced migration, and extensions caught fetching remote JavaScript are delisted immediately. Web Store reviewed and removed over 2.5 million policy-violating extension actions in 2024.

How do I pass Chrome Web Store security review faster?

Use the minimum permission set, ship a privacy policy for any extension requesting sensitive data, explain each permission in your listing description, and avoid eval() or innerHTML with external content. Reviewers use automated tooling that flags these patterns before a human ever looks at your submission.

What is the content script isolated world in Manifest V3?

Content scripts run in an isolated JavaScript context that shares the DOM but not global variables with the host page. The page cannot read your extension's variables, but you must still sanitize data you read from the DOM before passing it to background scripts, since a malicious page can write arbitrary content to DOM nodes you read.

If your extension connects to a backend, scan it for vulnerabilities before your users install.