Chromium

The first step could be to document the current behavior on developer.chromium.com. If anyone has time after that, perhaps a decision can be made on if this behavior should be changed.

We also have the same issue with our Chrome Extension, Tango.

This will likely break a lot of extensions, since use_dynamic_url: true is the default behavior of the package vite-plugin-webextension; all extensions that use that and a content script will break. I've confirmed that setting use_dynamic_url: false fixes the issue.

RE comment#3: Thanks for the heads up about this, and sorry about the trouble. We're looking into addressing this, but at the moment think it still makes sense to launch the feature. We'll try to fix it as soon as possible but it might not be before Chrome 130 goes to stable.

I've reached out to the plugin author here to see if they can update the default or provide some additional guidance in the meantime: https://github.com/samrum/vite-plugin-web-extension/issues/144

Note that the code uses an absolute path for import, not relative, because chrome.runtime.getURL transforms the string into an absolute path, so the title of the bug is incorrect.

Perhaps your comment in crbug.com/324975819#comment8 shows a better import line?

AFAICT, no, this bug doesn't depend on the path being relative, i.e. my point was that this word should be removed from the title. That comment you've linked shows a different example: using a relative path to load a second module file from the first module file loaded from the content script.

This also affects creating dynamic script elements which are added to the page from content script:

https://issues.chromium.org/issues/374013409

const element = document.createElement( 'script' );
element.src = chrome.runtime.getURL( 'script.js' );
document.head.appendChild( element );

Sounsd to me like the dynamic url should be part of the content security policy.

Has anyone found a definitive solution for CSP violation with chrome.runtime.getURL?

Hi everyone,

I've followed the recommendations in this thread to resolve the CSP violation when loading scripts using chrome.runtime.getURL, but I'm still encountering the same error. My extension was functioning correctly before, but the issue appeared after recent updates.

Error: Refused to load the script 'chrome-extension://139dd5ff-aafb-41b1-b61f-c524f015f41a/assets/main.tsx-d78cb075.js' because it violates the following Content Security Policy directive: "script-src 'self' 'wasm-unsafe-eval' 'inline-speculation-rules' http://localhost:* http://127.0.0.1:*". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

Here's the relevant code block:

(function () {
  'use strict';
  const injectTime = performance.now();
  (async () => {
    const { onExecute } = await import(
      /* @vite-ignore */
      chrome.runtime.getURL("assets/main.tsx-d78cb075.js")
    );
    onExecute?.({ perf: { injectTime, loadTime: performance.now() - injectTime } });
  })().catch(console.error);
})();

I've reviewed the following related issues:

https://github.com/crxjs/chrome-extension-tools/issues/927
https://github.com/samrum/vite-plugin-web-extension/issues/144
Despite following these recommendations, the issue persists. It seems related to recent CSP changes or updates.

Additional Information:

@crxjs/vite-plugin: ^2.0.0-beta.14
Development environment: Vite, CRXJS
Any guidance or insights on adjusting the CSP configuration or addressing recent changes would be greatly appreciated.

Thanks!

Hi, I'm the CRXJS maintainer, and I just wanted to voice my support for including dynamic URLs in the CSP when use_dynamic_url is true. The current implementation breaks import() in content scripts and affects chrome.runtime.getURL(), causing issues for all the extensions built with CRXJS and other tools that use ESM in content scripts.

Some use case background: Modern JS build tools are ESM-first, but content scripts don't support ESM except by import(). To leverage a fuller build tool feature set, we use import(). Dynamic URLs help to protect user privacy by preventing browser fingerprinting through extension URLs.

Including dynamic URLs in the CSP would:

1. Resolve these breaking changes
2. Maintain the privacy benefits of dynamic URLs
3. Support modern development practices in content scripts

I know Chrome extensions have many edge cases, and it's hard to move forward while supporting all of them. I appreciate all your hard work! Can I provide any extra information to help prioritize fixing this breaking change?

Edit: updated use case information

wOxxOm, could you share a link to the change you're referring to? Thanks all for the feedback - I'm hoping to have some discussions with the team this week to check in on how we might be able to prioritize this. I can't promise anything but we definitely hear you :)

Comment #15: That looks like a separate issue to me, and it's not one I've seen any other reports of. I'll make sure we take a look.

In case it helps at all, I created a minimal repro for this issue. (My browsers updated to 130 today and I ran into this issue with an extension I made.)

https://github.com/drmercer/webext-csp-issue-repro-oct2024

Workaround: drop "use_dynamic_url": true from the entry in web_accessible_resources. Note: unfortunately, that does have privacy implications. (Figured I'd include this for anyone skimming this thread and not seeing a clear workaround. 😅)

Project: chromium/src
Branch: main
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Link:      https://chromium-review.googlesource.com/5955629

[Extensions] Fix import of dynamic URL resources

[Extensions] Fix import of dynamic URL resources 
 
Extensions have a minimum CSP applied to their isolated worlds. This 
CSP restricts remotely-hosted code (by design) by limiting script 
sources to `self`. However, this causes problems when trying to 
`import()` resources that are exposed in web-accessible resources with 
`use_dynamic_url` set to true, since those resources will be (initially) 
served over the extension's dynamic origin. 
 
Modify the extension's isolated world CSP to explicitly allow resources 
from that extension's dynamic origin, and add a browsertest to exercise 
the same. 
 
Fixed: 363027634 
Change-Id: I73af26ce15e9164b544e9ee70f7c94ade162d6ef 
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5955629 
Reviewed-by: Tim <tjudkins@chromium.org> 
Commit-Queue: Devlin Cronin <rdevlin.cronin@chromium.org> 
Cr-Commit-Position: refs/heads/main@{#1373148}

RE comment #21: Could you share an example extension? That would be helpful so we can try to see what is happening. Based on the error message, I'm wondering if you are possibly using a relative path. In that case, you'd want to switch to import(chrome.runtime.getURL(... since this fix doesn't exempt content scripts from the other dynamic URL requirements.

@ #comment24: Unfortunately, this is unlikely to be merged into earlier releases.