How to Configure the Necessary Permissions for the Chrome Extension

Configure the necessary permissions for your Chrome extension by editing the host_permissions and permissions arrays in chrome-extension/manifest.ts, then rebuild the project to generate the final manifest.json.

The jonghakseo/chrome-extension-boilerplate-react-vite repository uses a TypeScript-based manifest configuration that compiles into the standard manifest.json required by Chrome Extension Manifest V3. Understanding how to properly configure these permissions ensures your extension can access required APIs and websites while following the principle of least privilege.

Understanding the Manifest Architecture

Unlike traditional extensions that edit manifest.json directly, this boilerplate defines permissions in chrome-extension/manifest.ts. The build process compiles this TypeScript file into dist/manifest.json automatically.

The configuration separates permissions into two distinct categories:

• host_permissions – URL patterns the extension can interact with, inject scripts into, or read data from.
• permissions – Chrome extension APIs the background service worker, content scripts, or UI pages are authorized to call.

Default Permissions in the Boilerplate

The repository ships with permissive defaults intended for development. In chrome-extension/manifest.ts at lines 33-35, you will find:

host_permissions: ['<all_urls>'],
permissions: [
  'storage',
  'scripting', 
  'tabs',
  'notifications',
  'sidePanel',
],

The '<all_urls>' pattern grants access to every website, which is convenient during development but should be restricted before publishing to the Chrome Web Store.

How to Configure Host Permissions

Restricting host permissions reduces your extension's attack surface and improves user trust. Replace the wildcard pattern with specific URL schemes that match your use case.

Restricting to Specific Domains

Edit chrome-extension/manifest.ts to declare only the domains your extension actually needs:

const manifest = {
  // ... other manifest properties
  host_permissions: [
    'https://api.myapp.com/*',      // Access your backend API
    'https://*.github.com/*',       // Access any GitHub subdomain
    'http://localhost:3000/*',      // Local development server
  ],
  // ...
};

After saving, the build system regenerates manifest.json with these restricted patterns. The extension will no longer be able to inject content scripts or read data from unspecified websites.

How to Configure API Permissions

The permissions array controls which Chrome APIs your extension can invoke. Add or remove entries based on the functionality you implement.

Adding New Permissions

To use additional Chrome APIs, append them to the permissions array in manifest.ts. For example, to enable the activeTab permission for temporary access to the current tab:

const manifest = {
  // ...
  permissions: [
    'storage',
    'scripting',
    'tabs',
    'notifications',
    'sidePanel',
    'activeTab',              // Newly added permission
  ],
};

With activeTab included, your service worker or popup can call chrome.tabs.executeScript on the currently active tab without requiring a permanent host permission for that URL.

Removing Unused Permissions

Eliminate unnecessary permissions to minimize security warnings during installation. If your extension does not dynamically inject scripts, remove the scripting permission:

const manifest = {
  // ...
  permissions: [
    'storage',
    // 'scripting',    // Removed - extension no longer injects scripts dynamically
    'tabs',
    'notifications',
  ],
};

This reduces the privilege surface and prevents accidental use of powerful APIs that your extension does not actually need.

Cross-Browser Considerations

The boilerplate supports both Chrome and Firefox through conditional manifest generation. In manifest.ts at lines 15-17, the code checks for Firefox and automatically strips unsupported permissions:

// Firefox does not support "sidePanel" permission
if (isFirefox) {
  manifest.side_panel = undefined;
}

When building for Firefox, the sidePanel permission is removed automatically, preventing validation errors during the Firefox Add-ons review process. Always verify that any new permissions you add are supported by your target browsers.

Rebuilding After Configuration Changes

After modifying manifest.ts, you must rebuild the extension to regenerate manifest.json. The build system handles TypeScript compilation and outputs the final JSON to the dist directory.

Run the development build to watch for changes:

pnpm dev

Or create a production build:

pnpm build

The generated dist/manifest.json reflects your updated permissions and is ready for loading into Chrome or packaging for the Web Store.

Summary

• Permissions are defined in chrome-extension/manifest.ts, not directly in manifest.json.
• host_permissions controls which URLs the extension can access; replace <all_urls> with specific domains for production.
• permissions controls which Chrome APIs are available; add only what your extension actively uses.
• Rebuild with pnpm dev or pnpm build after any changes to regenerate the final manifest.
• Firefox compatibility is handled automatically by stripping unsupported permissions like sidePanel.

Frequently Asked Questions

What is the difference between host_permissions and permissions in Manifest V3?

host_permissions defines URL patterns the extension can interact with, inject content scripts into, or read data from, while permissions grants access to specific Chrome extension APIs like storage, tabs, or scripting. Host permissions control where the extension runs, whereas API permissions control what the extension can do.

How do I add activeTab permission to my extension?

Open chrome-extension/manifest.ts, locate the permissions array, and add 'activeTab' as a new string element. This permission grants temporary access to the currently active tab only when the user invokes the extension, without requiring a permanent host permission for that URL.

Will my extension work on Firefox if I use sidePanel permission?

Yes, the boilerplate automatically removes the sidePanel permission when building for Firefox. The build script in manifest.ts checks for the Firefox target and sets manifest.side_panel to undefined, preventing validation errors while maintaining Chrome functionality.

Why should I avoid using <all_urls> in production?

Using <all_urls> grants your extension access to every website the user visits, which triggers severe security warnings during installation and violates the Chrome Web Store's principle of least privilege. Replace it with specific URL patterns matching only the domains your extension actually needs to reduce attack surface and improve user trust.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}