Scanner methodology

How the Chrome extension rejection checker works

See the static rules, limits, and review workflow behind the local Manifest V3 ZIP scanner.

Run local ZIP scan

Try the workflow

Run the same rules against your production ZIP

This page explains the rule model and limits. To apply the rules, go back to the tool page, select the ZIP you plan to submit, then export the Markdown checklist or JSON report after scanning.

Independent local static preflight only. This is not an official Chrome Web Store validation result.

Guide

What to check

Static package analysis

The scanner inspects the ZIP package structure and text files. It checks manifest location, manifest version, referenced files, sandbox page references, extension pages, JavaScript patterns, CSP script-src/worker-src/object-src, permissions, privacy signals, and icons.

Rule severity

High findings usually block or strongly affect submission readiness. Medium findings require permission, privacy, or listing review. Low findings are manual-review reminders for ambiguous remote URLs or context-dependent issues.

Limits

The scanner does not execute the extension, inspect Chrome Web Store Developer Dashboard fields, detect malware, audit runtime behavior, deobfuscate every possible dynamic URL construction, or guarantee approval. Large or unreadable files are skipped with partial-scan notes.

Static scan boundaries

Sandbox pages, unknown-size ZIP entries, source maps, fixture files, and dynamically assembled URLs can require manual review. The report marks partial-scan and confidence notes instead of treating a clean static result as approval proof.

Rules are mapped to official documentation

The scanner's visible findings are organized around official Chrome extension documentation for remote hosted code, MV3 CSP, sandbox pages, ZIP packaging, permissions, and privacy practices. It still cannot replace reviewer judgment or runtime policy review.

Practical notes

How to apply this before resubmission

Read severity as triage priority, not final policy judgment

The scanner assigns severity to help prioritize review. High means the package contains a strong static signal, such as a remote executable loader, unsafe extension-pages CSP value, missing root manifest, or broken manifest reference. Medium and Low findings often mean manual review is needed. They are not automatic policy violations, and a clean scan is not an approval guarantee.

  • High: fix first and rescan.
  • Medium: review against official docs and project context.
  • Low: document, confirm, or ignore only after manual review.
Scan a ZIP and review findings

Understand what static scanning cannot see

A local static scan cannot execute the extension, inspect Chrome Web Store dashboard fields, verify server responses, detect every obfuscated behavior, or decide whether reviewers will accept a disclosure. It is strongest at package-level checks that are visible in the submitted files. Use it before manual review, not instead of manual review.

  • Best at: manifest, CSP, referenced files, static JS/HTML patterns, scan limits.
  • Not enough for: runtime behavior, server-side responses, policy intent, final approval.
  • Use official Chrome docs as the final reference for each rule family.
Open the rejection workflow guide

How rules are grouped in the report

The report separates package findings from scan-limit notes. Findings describe detected code, manifest, CSP, permission, or privacy signals. Scan limits describe files that were skipped, size limits, unknown ZIP metadata, or partial-scan boundaries. This separation matters because a scan limit is not a policy violation; it tells you where manual inspection may still be needed.

  • High findings usually deserve a package change before resubmission.
  • Medium findings usually deserve manual confirmation or reviewer-note preparation.
  • Scan limits should trigger targeted manual inspection of skipped files.
Run a scan and review the separated report

Why confidence labels appear beside findings

Static scanning cannot understand every runtime path or reviewer decision. Confidence labels help separate high-confidence loader patterns from manual-review signals and possible non-runtime contexts. For example, a remote script URL assigned to a script loader is stronger than the same URL appearing inside documentation text or a source map comment.

  • Use high-confidence findings as direct repair targets.
  • Use manual-review findings to decide whether a signal is data, documentation, or executable code.
  • Remove noisy source maps or comments from release packages when they create review ambiguity.
Review remote hosted code findings

How official documentation maps to scanner checks

The scanner does not invent policy categories. Its rules map to public Chrome documentation: remote hosted code guidance, MV3 content security policy rules, sandbox rules, ZIP packaging guidance, permissions guidance, and privacy-practices documentation. The implementation still remains a static helper, so official docs and the Developer Dashboard remain the final reference for submission decisions.

  • Use source links to verify the rule family behind a finding.
  • Expect some findings to be conservative because static scanners prefer review prompts over silence.
  • Update scanner wording whenever Chrome documentation changes.
Open the local scanner

Checklist

Action checklist

  • Select the final production ZIP.
  • Fix High findings first.
  • Review Medium findings for permissions, privacy, icons, and listing clarity.
  • Use Low findings as manual review prompts.
  • Rebuild after changes and scan the rebuilt ZIP.
  • Keep reviewer notes aligned with the final package.
  • Review partial-scan notes when large files are skipped by browser safety limits.
  • Review sandbox.pages and content_security_policy.sandbox separately from extension_pages CSP.
  • Review skipped unknown-size files and any finding confidence notes before submission.
  • Compare scanner findings with the official source links listed on this page before treating a fix as complete.

Examples

Common cases this page helps with

High severity example

A remote JavaScript URL in popup.html is high severity because executable extension code should be bundled into the package.

Medium severity example

Broad host permissions may be valid, but they need least-privilege review and clear user-facing justification.

Low severity example

A remote URL in a web resource may be an API, image, documentation link, or data endpoint. Confirm it does not load executable code.

FAQ

Frequently asked questions

Why scan the production ZIP?

Build tools can change paths, bundle dependencies, and generate files. Chrome Web Store reviews the submitted ZIP, so scan that final artifact.

Why are some findings not automatic violations?

Some permissions and remote URLs are context-dependent. The scanner flags them so you can review purpose, disclosure, and implementation.

How often should rules be reviewed?

Review scanner rules whenever Chrome extension policies or Manifest V3 guidance changes, and record the last reviewed date in the changelog or documentation.

Which official docs does the scanner map to?

The core rules map to Chrome documentation for remote hosted code, Manifest V3 CSP, sandbox pages, ZIP packaging, privacy practices, and permission policies. The scanner shows these sources so each finding can be reviewed against the source of truth.

Official sources

Sources used for this page

These links are listed so scanner findings and page guidance can be checked against Chrome's source documentation. This site remains an independent preflight tool.

Related guides

Chrome Extension Rejection Checker is an independent local preflight scanner. It is not affiliated with Google or Chrome Web Store and does not guarantee approval.