So we "just" need to "not pass" the attributes to the script, that's right ?

So we "just" need to "not pass" the attributes to the script, that's right ?

In theory yes.

@nicolas-grekas do you remember why you added all the attributes ? to handle CSP ?

@nicolas-grekas do you remember why you added all the attributes ? to handle CSP ?

If CSP was the reason, adding strict-dynamic is enough to allow the injected script. No need to add nonce to the shim via setAttribute call.

I'm not fluent in CSP, I didn't think much of it. PR welcome.

@nicolas-grekas
I'm not sure how to fix this properly - there can be some edge-cases where a dev wants to add some attributes to the shim script tag.

strict-dynamic cannot be set on a single script, afaik :|

I'd suggest we remove any CSP attribute per default on the polyfill loading script.

Users can then chose to add custom attributes on this script (via config), or to hide it do things manually, etc etc

I got it working by duplicating the inline script block which dynamically creates the shim script tag and removing both the nonce attribute (so that the script block's code is identical across page visits) and the data-turbo-track attribute from the resulting script tag (as the shim is now dynamically added, it will be missing in the response body of Turbo page fetches which causes Turbo to think the assets have changed and performs a full page load).

I think removing these attributes on the resulting script tag would be the way to go:

• we can safely remove the data-turbo-track - if the shim version changes between Turbo visits, the inline script block will change as well (different paths / asset versions) and since it has data-turbo-track it will trigger a full page load
• for the nonce, the resulting script tag passes CSP under the self rule - I don't think importmaps even work without whitelisting the hosts in scripts-src CSP (self or hostname), even if the script tag with type=importmap has a nonce

On the other hand, the AssetMapper docs mention adding strict-dynamic to CSP script-src for CSS loading, which would partially fix this issue as well. But from my understanding, if you add strict-dynamic on Turbo-powered apps, you basically empower Turbo to execute all inline scripts it founds on future page visits, even if they normally would not pass CSP nonce or hash validations on full-page loads. While this would allow the execution of the script block loading the ES Module shim with the random nonce, it could also potentially allow malitious injected scripts, defeating the purpose of CSP. And the data-turbo-track=reload attribute would still this trigger a full-page reload on every Trubo visit.

We encountered the same issue after upgrading from AssetMapper 7.1 to 7.2 in a project that uses symfony/ux-turbo. Form submissions reloaded page instead of replace. Adding data-turbo-track: dynamic to asset_mapper.yaml fixed this issue:

    asset_mapper:
        importmap_script_attributes:
            data-turbo-track: dynamic

Side note: After upgrading AssetMapper, we also had to allow script-src: strict-dynamic in nelmio_security config. Without it, we saw following errors in browser console:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' ... data: 'nonce-j9qZU0a7Sjrx5O+kla4cVg==' 'unsafe-inline' 'nonce-b8c0b3da51b4d3c9917134dca9a1d5f7'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.