CSP Enforcement blocks SPFx script even its CDN URL has been imported from the App Catalog

[jbolliet-mozzaik365]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

other (enter in the "Additional environment details" area below)

Developer environment

None

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

SharePoint Admin Center

Describe the bug / error

Microsoft recently introduced Content Security Policy (CSP) enforcement in SharePoint Online, and the new Trusted Script Sources configuration is now available in the admin center.

On my tenant, all my SPFx solution deployments automatically add their CDN script URLs into Trusted Script Sources as expected.
However, when navigating to any page containing my SPFx web parts and adding the query string ?csp=enforce, SharePoint still blocks the script, even though the exact CDN URL appears in the list of trusted sources and is marked as Imported from app catalog.

In the browser console, I receive this error (domain and webpart anonymized + well formated):

Loading the script 'https://cdn.{my-domain}.net/webparts/prd/2025.11.25.64207/{my-webpart}_0c261bde6389a7ca3ea2.js' violates the following Content Security Policy directive: "script-src 'unsafe-eval' 
https://cdn.{my-domain}.net/webparts/prd/2025.6.4.55003 
https://cdn.{my-domain}.net/webparts/prd/2025.6.18.55826 
https://cdn.{my-domain}.net/webparts/prd/2025.6.20.55920 
https://cdn.{my-domain}.net/webparts/prd/2025.7.16.57858 
https://cdn.{my-domain}.net/webparts/prd/2025.7.21.58232 
https://cdn.{my-domain}.net/webparts/prd/2025.8.8.59141 
https://cdn.{my-domain}.net/webparts/prd/2025.8.11.59281 
https://cdn.{my-domain}.net/webparts/prd/2025.8.13.59486 
https://cdn.{my-domain}.net/webparts/prd/2025.9.10.61049 
https://cdn.{my-domain}.net/webparts/prd/2025.9.11.61069 
https://cdn.{my-domain}.net/webparts/prd/2025.9.11.61102 
https://cdn.{my-domain}.net/webparts/prd/2025.9.16.61451 
https://cdn.{my-domain}.net/webparts/prd/2025.9.19.61762 
https://cdn.{my-domain}.net/webparts/prd/2025.9.24.62135 
https://cdn.{my-domain}.net/webparts/prd/2025.10.7.62692 
https://cdn.{my-domain}.net/webparts/prd/2025.10.8.62741 
https://cdn.{my-domain}.net/webparts/prd/2025.10.14.63049 
https://cdn.{my-domain}.net/webparts/prd/2025.10.20.63172 
https://cdn.{my-domain}.net/webparts/prd/2025.10.23.63294 
https://cdn.{my-domain}.net/webparts/prd/2025.10.30.63595 
https://cdn.{my-domain}.net/webparts/prd/2025.11.5.63741 
https://cdn.{my-domain}.net/webparts/prd/2025.11.18.63986 
https://cdn.{my-domain}.net/webparts/prd/2025.11.25.64207  <===== CDN URL automatically imported into Trusted Script Sources
https://contentstorage.osi.office.net 
https://swx.cdn.skype.com 
https://res.delve.office.com 
https://lpcres.delve.office.com 
https://widget.uservoice.com 
https://by2.uservoice.com 
https://www.bing.com/api/maps 
https://www.bing.com/rms 
https://fabriciss.azureedge.net 
https://ajax.aspnetcdn.com 
https://js.monitor.azure.com 
https://r4.res.office365.com 
https://public-cdn.sharepointonline.com 
https://teams.microsoft.com 
*.cdn.office.net 
*.fluidpreview.office.net 
*.onecdn.static.microsoft 
https://webshell.suite.office.com 
https://amcdn.msftauth.net 
https://res-1.cdn.office.net 
https://res-1.public.onecdn.static.microsoft 
*.bing.com 
c64.assets-yammer.com 
*.virtualearth.net 
*.ditu.live.com 
appsforoffice.microsoft.com 
platform.twitter.com 
https://login.microsoftonline.com 
https://publiccdn.sharepointonline.com 
https://public-cdn-staging.sharepointonline.com 
https://loki.delve.office.com 
https://res.cdn.office.net/midgard/ 
https://substrate.office.com 
https://res.public.onecdn.static.microsoft  
https://c1-word-view-15.cdn.office.net 
'self' 
alcdn.msauth.net 
https://res-2.public.onecdn.static.microsoft 
https://res-3.cdn.office.net 
https://shell.cdn.office.net 
https://res.cdn.office.net 
'nonce-y188x3lm66' 
'sha256-ATReICQsd+smV/PvrA4eH+DuxsenS4SxbGcSjySJlBA=' 
'sha256-2vr5KMButMK7a+bOf/ned/cPnF2yNooMulXA8E65wGw=' 
'sha256-Ie4uWHgjrKA4WjOrgfxpFEHOCYe/wqVItoHI+ySGTd4='". 
Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. 
The action has been blocked.

The CSP violation explicitly lists the correct versioned folder (2025.11.25.64207), confirming that SharePoint knows the source is trusted — but still blocks the script.

The result is that SPFx components fail to load when CSP is enforced, even though the tenant configuration is correct.

This seems to indicate either:

• a CSP evaluation bug,
• or a mismatch between how SharePoint imports trusted sources from the App Catalog and how the CSP engine evaluates them at runtime.

Steps to reproduce

1. Deploy an SPFx solution to the App Catalog using a CDN hosted script (e.g. https://cdn.domain.net/webparts/prd/<version>/).
2. Verify in SharePoint Admin Center → Content Security Policy → Trusted Script Sources that the CDN URL is automatically added with status Imported from app catalog.
3. Add the SPFx web part to a modern page.
4. Load the page using the query parameter:
   ?csp=enforce
5. Open the browser console.

Actual result:
A CSP error appears, indicating that the script violates the script-src directive — even though the CDN URL is listed in Trusted Script Sources.

Expected behavior

When a script URL is present in Trusted Script Sources (automatically imported from the App Catalog), SharePoint should allow the script to load during CSP enforcement.
The SPFx web part should load normally without CSP violations.

[MortenGuldbaek]

Is https://cdn.{my-domain}.net/webparts/prd/2025.11.25.64207 your actual script name? I ran into issues where a missing appended forward slash was required

[jansenbe]

@jbolliet-mozzaik365 : can you try with explicitly adding https://cdn.{my-domain}.net/webparts/prd/2025.11.25.64207/{my-webpart}_0c261bde6389a7ca3ea2.js as trusted source and see if that works? Also, I've noticed that sometimes you need to reload (CTRL-R) the browser session a few times before changes are picked up.

[rgcircum]

If it helps, I've had a similar problem since Monday evening (GMT). It happens with web parts that are in the site collection's application catalog.

It also happens with files stored on the Microsoft CDN (https://public-cdn.sharepointonline.com/).

On my tenant, the tenant's application catalog doesn't seem to be affected, just the site collection app catalog. I have no solution (clearing the cache doesn't change anything).

It happened suddenly, without any changes (no wbepart deployments on my end).

Error :

Access to fetch at 'https://public-cdn.sharepointonline.com/***/sites/***/ClientSideAssets/9ed633b7-0cad-49eb-836b-ca786a9f18f0/***_50753639c3edee2f4f99.js' from origin 'https://***.sharepoint.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[jbolliet-mozzaik365]

@jansenbe , @MortenGuldbaek ,
Thank you for your suggestions!
I can confirm that adding a trailing slash to the URL auto-imported by SharePoint, from the package deployed in the App Catalog, removes the issues we were seeing.
This clearly indicates a bug, as these automatically generated URLs should work out of the box without requiring manual adjustments.
Note that this behavior does not occur on all tenants, which is rather surprising.

[MortenGuldbaek]

Our findings show that we are having to suffix the cdnBasePath (in /config/write-manifests.json) with a trailing slash to ensure it is not handled as a single script, but rather a directory allowed to load multiple scripts.

Doing this ensures that our extensions and webparts are loaded correctly when forcing CSP compliance (?csp=enforce).

However, for some reason, the new cdnBasePath is still reported by SharePoint as a CSP violation, even though the script loads and the extension runs.

In the attached screenshot, the green redacted bar represents our CDN URL ending with the trailing slash /

@jansenbe can you comment on if this is overzealous reporting or if we will indeed be limited if using a trailing slash approach?

(Private domains redacted)

[jansenbe]

@MortenGuldbaek : can you share the url in trusted sources and your actual script url here. Please put contoso as your tenant name and pick a fake product/script name to ensure your data in anonymous

[MortenGuldbaek]

@jansenbe certainly, here you go:

Note: CDN is hosted on Azure, not SharePoint.
Host, sub-domain, and path have been anonymized.

Trusted script sources record
https://mycdnonazure.contoso.com/assets/99999/

Actual extension script (one of many) loaded in SharePoint
https://mycdnonazure.contoso.com/assets/99999/ex-tension_a91b2e6c3d4f5g6h7i8.js

URL reported as blocked violation in console (matches the Base Path)
https://mycdnonazure.contoso.com/assets/99999/

[jansenbe]

@MortenGuldbaek : I assume you've done a few CTRL-R's to fully refresh the page. Just to confirm CSP is working: when you add https://mycdnonazure.contoso.com (no trailing slash) the scripts are loaded?

[jansenbe]

@MortenGuldbaek : do you see the same behavior when you test on regular page versus a list page?