Dynamic code execution

Chrome extension eval() and dynamic code rejection fix

Find eval, new Function, and string-based timers that can trigger Chrome extension CSP and review problems.

Run local ZIP scan

Dynamic code preflight step

Check the packaged extension for eval-style patterns

Upload the final ZIP to scan generated scripts and extension pages for eval(), new Function(), string timers, legacy executeScript code strings, DevTools eval calls, and CSP settings that may require manual review.

Scan for eval and dynamic code Review CSP rules

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

Guide

What to check

Why eval is risky

String-code execution makes extension behavior harder to review and often conflicts with extension page CSP restrictions. It can also hide remote-code-like behavior from a static review.

Patterns to replace

Replace eval, Function constructors, and string-based setTimeout or setInterval calls with normal functions, modules, command maps, JSON parsing, or structured data.

How this scanner helps

The report shows the file, line, snippet, reason, and recommendation so developers can quickly remove dynamic code execution patterns from the submitted ZIP.

Check extension pages before sandbox exceptions

Unsafe dynamic code patterns should be removed from extension pages first. If a sandbox workflow is used, the sandbox CSP and page isolation need separate manual review because it follows different rules than extension_pages.

Practical notes

How to apply this before resubmission

Replace string execution with bundled functions or modules

Dynamic string execution is hard to review because the code may not exist as a static file in the submitted ZIP. Replace eval, Function constructors, string timers, and legacy executeScript code strings with named functions, imported modules, or declarative data that is interpreted by bundled code. This makes the executed logic visible in the package and easier to check against MV3 CSP expectations.

  • •Move command maps into objects or switch statements.
  • •Replace template-generated functions with ordinary imported functions.
  • •Avoid passing strings to timer or tab execution APIs.
Scan for eval and dynamic code patterns

Use sandbox pages deliberately, not as a shortcut

Some extension designs use sandboxed pages for isolated execution contexts, but sandbox pages have a separate manifest declaration and a separate CSP. They should not be used to bypass ordinary extension-pages restrictions without understanding Chrome’s sandbox requirements. The scanner flags sandbox pages and checks key CSP mistakes, but runtime design still needs manual review.

  • •Confirm sandbox.pages points to packaged files.
  • •Confirm custom sandbox CSP includes the sandbox directive.
  • •Do not include allow-same-origin in sandbox CSP.
See how CSP checks work

Find dynamic execution before editing CSP

When an extension shows eval-related errors, changing the CSP is rarely the right first move in Manifest V3 extension pages. Locate the dynamic execution path first: direct eval, new Function, string timers, legacy executeScript code strings, devtools eval helpers, or a vendor bundle that generates functions at runtime. Replace the runtime string execution with imported functions, data-driven switches, or build-time compilation.

  • •Search the final bundle, not only source files.
  • •Treat unsafe-eval in extension_pages CSP as a package blocker.
  • •Check vendor and WASM bootstrap output for generated function calls.
Scan for eval and dynamic code patterns

When sandbox pages are appropriate

Sandbox pages are a separate extension context, not a way to loosen the CSP for normal extension pages. Use them only when you intentionally isolate an untrusted or dynamic execution surface and can keep it away from privileged extension APIs. The scanner flags sandbox CSP problems separately because extension_pages CSP and sandbox CSP have different rules and different review implications.

  • •Do not move privileged extension logic into sandbox pages.
  • •Ensure custom sandbox CSP keeps the required sandbox directive.
  • •Avoid allow-same-origin in sandbox CSP because it breaks the intended isolation boundary.
Review sandbox and CSP checks

Fix patterns for generated bundles

Eval-like code sometimes arrives through bundler settings rather than application code. Development source maps, template compilers, WASM glue code, and worker plugins can introduce generated function constructors or inline string execution. For a release build, use production-safe bundler settings, remove development-only source-map modes that rely on eval, and verify that the packaged output no longer contains those patterns.

  • •Disable eval-based source-map modes for extension releases.
  • •Audit generated vendor chunks after dependency upgrades.
  • •If WASM is required, confirm the loader pattern matches MV3 CSP constraints.
Re-scan the release package after bundler changes

Checklist

Action checklist

  • □ Search for eval calls in background, popup, options, and content scripts.
  • □ Replace new Function with explicit functions or a command map.
  • □ Replace string-based setTimeout and setInterval with function callbacks.
  • □ Check bundled vendor files for dynamic-code helpers.
  • □ Rebuild and scan the production ZIP again.

Examples

Common cases this page helps with

Command string passed to eval

Replace eval(command) with a map such as actions[commandName](payload), where commandName is validated and action functions are bundled.

new Function template evaluator

Replace runtime function construction with precompiled templates, safe expression parsing, or a limited set of local handlers.

String timer callback

Replace setTimeout("runTask()", 1000) with setTimeout(() => runTask(), 1000).

FAQ

Frequently asked questions

Does every eval occurrence cause rejection?

The scanner treats eval as high risk because it is commonly incompatible with extension CSP and review expectations. Review and remove it when possible.

Can minified vendor code contain dynamic execution?

Yes. Scan the final ZIP because bundled dependencies can introduce eval-like patterns that are not obvious in your own source files.

What is the safest replacement?

Use explicit local functions, static imports, command maps, and structured data. Avoid constructing executable code from strings.

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.

Chrome Extensions: Manifest content security policy

Documents extension_pages and sandbox CSP policies, default policies, and MV3 minimum CSP restrictions.

Chrome Extensions: Manifest sandbox

Documents sandbox.pages and the sandbox CSP requirements, including the sandbox directive and allow-same-origin restriction.

Chrome Extensions: Deal with remote hosted code violations

Defines remotely hosted code as browser-executed JS/WASM loaded outside the extension package and recommends scanning compiled submission output for http/https references.

Related guides

Continue review

Run the local ZIP scanner Fix remote hosted code in Manifest V3 Manifest V3 pre-submission checklist Run local ZIP scan

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.