Chrome applies a content security policy to every Manifest V3 extension page. The default is script-src 'self' and object-src 'self', which means scripts and objects load only from the extension's own packaged files. Inline scripts and string evaluation are off, and you cannot relax the policy below a fixed minimum.
The default policy
Google's reference gives the default for extension pages as:
script-src 'self'; object-src 'self';
In practice this blocks:
- Loading scripts or objects from anywhere outside the extension's own files.
- Inline JavaScript and evaluating strings as code.
- WebAssembly, under the default policy.
If a developer asks for something looser than Chrome's minimum, such as 'unsafe-eval' in script-src, Chrome rejects it at install time.
What can be changed
The page says developers can add or remove rules, or use the minimum policy. The minimum Chrome enforces is:
script-src 'self' 'wasm-unsafe-eval'; object-src 'self';
That permits WebAssembly but nothing beyond it. So an extension can ask for WebAssembly support, but it cannot opt into remote script loading through the policy.
Sandbox pages are a separate case
Extensions can declare sandboxed pages with a much looser policy. The default sandbox policy allows inline scripts and eval, with flags like allow-scripts, allow-forms, allow-popups and allow-modals, and child-src limited to 'self'. The tradeoff, per the same page, is that sandbox pages have no access to extension APIs and no direct access to non-sandboxed pages.
This is useful for a library that needs eval, such as certain template engines, because the risky code lives in a box with no extension powers.
What a reviewer should look for
- Does the manifest set a custom
content_security_policyat all? Most extensions should not need one. - If there is one, what does it add? A policy that adds remote hosts to script-src would be surprising under Manifest V3.
- Are there sandbox pages, and what do they do with the data they receive?
Content scripts have their own rules. Google's content script page says isolated world scripts have a policy that blocks eval and loading external scripts. For the wider picture on remote code, read the remotely hosted code rule.
Why this matters for you
The policy is a safety net for developers: even if an attacker injects markup into an extension page, inline scripts will not run. It is not a defense against a developer who ships bad code inside the package, and it does not limit where data can be sent. Google notes the default policy does not restrict connections to hosts.
Quick check
Can a Manifest V3 extension allow unsafe-eval on its pages?
No. Google's reference says Chrome rejects it at install time, and the policy cannot be relaxed beyond the minimum.
Does the CSP stop an extension sending my data to a server?
No. The default policy does not restrict connections to hosts, so network access is governed by permissions and host access, not this policy.
Sources
Last reviewed: 19 October 2026.
