Chrome Extension Security: The Manifest V3 Review Checklist (2026)

When the Chrome Web Store rejects your extension, the email does not say "too many permissions." It says Purple Potassium. Chrome names every violation with a colour and a chemical element, publishes what each one means, and expects you to look yours up. Ask an AI assistant to "build a Chrome extension that saves the page I'm on" and the manifest it writes will request <all_urls> and tabs, which is the exact shape that earns that code.

This checklist is ordered the way review is: the items that get you rejected or delisted first, then the ones that keep you from being exploited later. Each item names the manifest key it maps to and, where one exists, the rejection code it prevents.

Manifest V3: What Actually Changed for Security

The Web Store stopped accepting new public V2 extensions in January 2022 and private ones that June, so V3 has been the only way in for years. What changed recently is the other end: enforcement finished. Three of the changes matter for security.

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.

Read the Rejection Code, Not the Rejection Email

Most people resubmit after a rejection with a guess about what upset the reviewer. Chrome publishes the answer. Every rejection carries a code built from a colour and a chemical element, and Chrome's troubleshooting page lists what each one means. These are the ones a security-focused extension actually runs into:

The four Purple codes are one family, and they are worth reading together: they are Chrome's user-data policy, split by which part you broke. Three of them (Lithium, Nickel, Magnesium) can be triggered by an analytics call you added without thinking about it.

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.

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
});