Due to the Host Permission Your Extension May Require an In-Depth Review: Fix It Now

You hit submit. Everything looks good. Then this red banner appears:

“Due to the Host Permission, your extension may require an in-depth review which will delay publishing.”

Your stomach drops. You have no idea how long “delay” means. Days? Weeks? You have users waiting.

Here’s the honest truth: that warning isn’t a rejection, and it’s not random. Google added it for a specific reason, it’s triggered by specific patterns in your manifest, and — most of the time — you can fix it in under an hour.

This guide walks through exactly what triggers the warning, what “in-depth review” actually entails, realistic timelines, and the four refactoring strategies that make it go away.

What the Warning Actually Means

The Chrome Web Store developer dashboard shows this warning when your extension requests permissions that give it broad access to browse activity across multiple websites — before any user interaction happens.

Google’s core concern is simple: an extension that can silently read or modify any page on the web is a significant privacy risk. The in-depth review exists so a human reviewer can verify the extension doesn’t abuse that access. Automated checks aren’t enough; the reviewers want to understand why your extension needs to touch every website.

This is not a policy violation — yet. It’s a flag that says “we need to look closer.” But it adds time, and time is brutal when you’re trying to launch.

The 4 Manifest Patterns That Trigger It

Not every permission causes this. The in-depth review warning fires when your manifest contains one or more of these patterns:

1. <all_urls> in content_scripts.matches

"content_scripts": [
  {
    "matches": ["<all_urls>"],
    "js": ["content.js"]
  }
]

This is the most common trigger. You’re telling Chrome: “inject my script on every single website the user visits, automatically, without them doing anything.” From Google’s perspective, that’s the same capability a keylogger would use.

2. Broad wildcard in host_permissions

"host_permissions": ["*://*/*"]

Same problem, different declaration. Wildcard patterns that cover the entire web — *://*/*, http://*/*, https://*/* — trigger the flag. Even *://*.com/* is broad enough to warrant scrutiny depending on reviewer judgment.

3. Multi-domain wildcards

"host_permissions": [
  "*://*.google.com/*",
  "*://*.github.com/*",
  "*://*.stackoverflow.com/*",
  "*://*.twitter.com/*",
  "*://*.linkedin.com/*"
]

Five or more unrelated domains can sometimes draw the same scrutiny, particularly if they include high-value targets like financial or social sites. Fewer, more specific patterns generally fare better.

4. Combining tabs + broad host access

"permissions": ["tabs"],
"host_permissions": ["*://*/*"]

The tabs permission paired with broad host access gives an extension the ability to read URLs, titles, and favicons across every open tab while also being able to modify page content. That combo gets extra attention.

What “In-Depth Review” Actually Entails

When Google’s automated system flags your submission for in-depth review, it gets placed in a queue for manual human review. Here’s what that looks like in practice:

A reviewer examines your extension’s code, your privacy practices disclosure, your store listing, and any justification you’ve written for each permission. They’re asking:

• Does the functionality described actually require access to all these sites?
• Is the privacy policy consistent with what the code actually does?
• Is there obfuscated code trying to hide behavior?

The reviewer doesn’t contact you during this process unless they need clarification. You just wait.

Real timelines from developer forum reports (2024–2025): Most in-depth reviews resolve within 1–2 weeks. Some take 3–4 weeks, particularly for new developer accounts or extensions with significant amounts of code. The Chrome Web Store documentation itself says that if you’ve been waiting more than three weeks, you should contact developer support via the One Stop Support form.

The standard (non-in-depth) review process gets most submissions done in under 24 hours. That gap is painful.

Strategy 1: Switch to activeTab + scripting (The Best Fix)

This is the right solution for the majority of extensions that run content scripts in response to user action — things like clicking a browser action button, right-clicking a context menu item, or pressing a keyboard shortcut.

The activeTab permission grants temporary access to the currently active tab only when the user invokes the extension. No persistent background access. No access to any other tab. Just the one the user is looking at, right now, because they asked for it.

Before — triggers the warning:

{
  "manifest_version": 3,
  "name": "My Extension",
  "permissions": ["contextMenus"],
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"]
    }
  ]
}

After — no warning:

{
  "manifest_version": 3,
  "name": "My Extension",
  "permissions": ["contextMenus", "activeTab", "scripting"]
}

You’ll need to update your background service worker to inject the script on demand using chrome.scripting.executeScript():

// background.js
chrome.contextMenus.onClicked.addListener(async (info, tab) => {
  await chrome.scripting.executeScript({
    target: { tabId: tab.id },
    files: ["content.js"]
  });
});

The tradeoff: your content script no longer runs automatically on page load. It only fires when the user takes action. For most extensions, that’s actually the right behavior anyway.

Strategy 2: Use optional_host_permissions

If your extension has features that require broad access optionally — say, an advanced mode that works on any site — you can move those permissions out of required host_permissions into optional_host_permissions.

{
  "manifest_version": 3,
  "name": "My Extension",
  "permissions": ["activeTab", "scripting"],
  "optional_host_permissions": ["*://*/*"]
}

Then request them at runtime using the chrome.permissions.request() API:

chrome.permissions.request({
  origins: ["*://*/*"]
}, (granted) => {
  if (granted) {
    // enable broad access features
  }
});

This approach removes the broad permission from your required manifest, meaning it doesn’t trigger the warning at submission time. Users who need the advanced feature grant access explicitly. Everyone else doesn’t see the permission at all.

Strategy 3: Narrow Your Match Patterns

If your extension genuinely only needs to run on specific sites, list only those sites. Don’t reach for <all_urls> out of convenience.

"host_permissions": [
  "https://github.com/*",
  "https://gitlab.com/*"
]

This is both more honest and less risky. Two specific domains are easy to justify. “All URLs” requires a much stronger explanation.

The Chrome Web Store review team looks for whether the permissions match the stated purpose. A code review tool that requests only GitHub and GitLab? Clear. A to-do list app requesting <all_urls>? Suspicious.

Strategy 4: When Broad Permissions Are Unavoidable

Look, sometimes you genuinely need <all_urls>. Password managers, accessibility tools, developer utilities that work on any page — these legitimately require broad access.

If you’re in this camp, don’t try to hide it. Here’s how to make the case clearly:

In the Privacy Practices tab of your developer dashboard:

Write a specific, detailed justification for each broad permission. Not “needed for functionality.” Something like:

“The extension injects a toolbar on any user-visited page to allow annotation. Access to all URLs is required because the user may want to annotate any website they visit. The extension does not collect, transmit, or store page content — it only modifies the DOM locally to render the annotation UI.”

The reviewers are checking whether you understand what you’re doing, and whether you’re being transparent about it.

Make sure your privacy policy matches. If your extension doesn’t collect data, say that explicitly in your privacy policy and in the justification fields. Mismatches between the code behavior and stated policy are a fast path to rejection.

What NOT to do:

• Don’t request broad permissions “just in case” you need them later
• Don’t use obfuscated code — it’s against policy and guarantees closer scrutiny
• Don’t lie about functionality to minimize the apparent scope of permissions
• Don’t resubmit repeatedly without changing anything — it won’t speed things up

The Appeals Process

If your extension was rejected after in-depth review, you have one appeal. That’s not a typo — one. Google’s Chrome Web Store policy allows a single appeal per policy violation.

To file it:

1. Go to your Chrome Web Store Developer Dashboard
2. Click on your extension
3. Click the Appeal button on the item detail page
4. Fill out the form with as much specific detail as possible

The appeal response typically arrives within three business days. Use this as your opportunity to address every specific concern raised in the rejection, not to argue that you were treated unfairly.

If you haven’t been rejected but are stuck in extended in-depth review, use the One Stop Support form to ask for a status update after three weeks.

Quick Reference: activeTab vs host_permissions

Refactor Your Manifest Today

The in-depth review warning is fixable. For most extensions, switching to activeTab + scripting takes less than an hour and eliminates the delay entirely. For cases where broad access is genuinely necessary, the path is honest justification — not clever workarounds.

If you’re building or migrating an extension and want to check your manifest against common review triggers, try the free tools at appbooster.net/tools — including the MV2-to-MV3 converter that flags permission issues before you submit.

Once your extension is published, the next challenge is building social proof. Read the AppBooster blog for strategies on getting your first real reviews from actual users — without risking your listing.

Sources:

• Permission warning guidelines — Chrome for Developers
• Declare permissions — Chrome for Developers
• Chrome Web Store review process — Chrome for Developers
• Avoiding a “Host Permission” Review Delay — Alex MacArthur
• Publishing delayed — Broad host permissions (developer forum thread)