Chrome Extension Security Audit Checklist

Browser extensions operate in one of the most privileged environments in computing. They can read every page a user visits, modify network requests, access cookies, and interact with sensitive APIs. A single vulnerability in a popular extension can compromise millions of users overnight.

In 2025 alone, over thirty Chrome extensions with combined install bases exceeding 2.5 million users were found to contain malicious code or critical vulnerabilities. Most of these were not sophisticated attacks — they exploited basic security oversights that a structured audit would have caught.

This checklist is your systematic framework for auditing Chrome extension security. Whether you are reviewing your own code or evaluating a third-party extension, work through each phase methodically. Skip nothing.

Phase 1: Permission Audit#

Permissions are the attack surface. Every permission your extension requests is a capability that can be exploited if your code is compromised. The principle of least privilege is not a suggestion — it is your primary defense.

The most common permission over-reach we see in audits:

// BAD — requests access to every website
{
  "permissions": ["tabs", "storage", "cookies"],
  "host_permissions": ["<all_urls>"]
}
 
// GOOD — requests only what's needed
{
  "permissions": ["storage"],
  "optional_permissions": ["tabs"],
  "host_permissions": ["https://api.yourservice.com/*"]
}

The tabs permission deserves special scrutiny. Without it, chrome.tabs.query() still returns tab IDs and basic info. With it, you also get url, title, and favIconUrl — which means full browsing history visibility. Only request tabs if you genuinely need URL access.

Phase 2: Content Security Policy#

Manifest V3 enforces stricter CSP defaults than V2, but "stricter" does not mean "secure." Your CSP configuration determines whether an attacker who finds an injection point can execute arbitrary code.

// manifest.json — Secure CSP configuration
{
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'none'; base-uri 'self';"
  }
}

The critical rule: never load remote scripts. Every JavaScript file your extension executes must be bundled in the extension package. This is enforced by MV3 for extension pages, but content scripts can still inject <script> tags into web pages that load remote code — and attackers know this.

Phase 3: Input Validation and Injection Prevention#

Every data flow into your extension is a potential injection vector. Messages from content scripts, data from storage, URL parameters, and clipboard contents all need sanitization before they touch the DOM or are used in API calls.

These numbers come from aggregate audit data across extension security research. The XSS figure is particularly alarming — nearly every extension that renders dynamic content has at least one path where unsanitized data reaches innerHTML.

Message Validation#

// VULNERABLE — no sender validation, no input sanitization
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  document.getElementById('output').innerHTML = message.data;
});
 
// SECURE — validates sender, sanitizes input, uses textContent
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  // Verify the message comes from our own extension
  if (sender.id !== chrome.runtime.id) {
    console.warn('Message from unknown sender:', sender.id);
    return;
  }
 
  // Validate message structure
  if (typeof message?.data !== 'string' || message.data.length > 10000) {
    return;
  }
 
  // Use textContent instead of innerHTML to prevent XSS
  const output = document.getElementById('output');
  if (output) {
    output.textContent = message.data;
  }
});

DOM Injection Safety#

When your extension needs to inject HTML into web pages via content scripts, the risk surface expands dramatically. The web page's JavaScript can observe and manipulate anything you inject.

// VULNERABLE — injecting HTML string into hostile page
function showNotification(text: string) {
  document.body.innerHTML += `<div class="ext-notify">${text}</div>`;
}
 
// SECURE — using Shadow DOM for isolation
function showNotification(text: string) {
  const host = document.createElement('div');
  const shadow = host.attachShadow({ mode: 'closed' });
 
  const container = document.createElement('div');
  container.textContent = text; // textContent, never innerHTML
 
  const style = document.createElement('style');
  style.textContent = `.notify { position: fixed; top: 16px; right: 16px;
    background: #1a1a2e; color: #fff; padding: 12px 20px;
    border-radius: 8px; z-index: 2147483647; font-family: system-ui; }`;
 
  container.className = 'notify';
  shadow.appendChild(style);
  shadow.appendChild(container);
  document.body.appendChild(host);
 
  setTimeout(() => host.remove(), 5000);
}

The mode: 'closed' shadow DOM prevents the host page's JavaScript from accessing your injected elements via element.shadowRoot. This is critical for extensions that display sensitive information on web pages.

Phase 4: Storage Security#

Phase 5: Network Security#

Every HTTP request your extension makes is a potential data leak or interception point. This phase reviews how your extension communicates with external services.

// Secure API communication pattern
const API_BASE = 'https://api.yourextension.com/v1';
 
interface ApiResponse<T> {
  data: T;
  error: string | null;
}
 
async function secureRequest<T>(
  endpoint: string,
  options: RequestInit = {}
): Promise<ApiResponse<T>> {
  const token = await getEncryptedToken(); // Retrieved and decrypted from storage
 
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), 10000); // 10s timeout
 
  try {
    const response = await fetch(`${API_BASE}${endpoint}`, {
      ...options,
      signal: controller.signal,
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}`,
        ...options.headers,
      },
    });
 
    clearTimeout(timeout);
 
    if (!response.ok) {
      // Don't log response body — it might contain sensitive data
      return { data: null as T, error: `Request failed: ${response.status}` };
    }
 
    const data = await response.json();
    // Validate response shape before trusting it
    if (!isValidResponseShape<T>(data)) {
      return { data: null as T, error: 'Invalid response format' };
    }
 
    return { data, error: null };
  } catch (err) {
    clearTimeout(timeout);
    return { data: null as T, error: 'Network request failed' };
  }
}

Phase 6: Third-Party Dependencies#

Supply chain attacks are the fastest-growing threat vector for browser extensions. A single compromised npm package can inject malicious code into your extension at build time.

Vulnerability Severity Distribution#

Based on aggregate data from extension security audits, here is where most vulnerabilities fall in terms of severity:

The bulk of findings are medium severity — things like overly broad permissions, missing sender validation on messages, and storage of sensitive data without encryption. These are not dramatic exploits, but they are the building blocks an attacker chains together to achieve a critical impact.

Common Attack Patterns to Test For#

Automated Security Scanning#

Manual audits are essential, but automated tooling catches low-hanging fruit faster. Integrate these into your CI pipeline:

# Run npm audit for dependency vulnerabilities
npm audit --production --audit-level=high
 
# Use retire.js to check for known vulnerable libraries
npx retire --js --path ./dist/
 
# Scan for hardcoded secrets
npx secretlint "src/**/*"
 
# Static analysis for common extension vulnerabilities
# (hypothetical tool - use CRXcavator or similar in practice)
npx extension-audit ./dist/manifest.json

For more on building secure extensions, see our guides on Manifest V3 Permissions Best Practices and the Complete Guide to Manifest V3. Understanding the permission model deeply is the foundation of extension security.