SharePoint Ignores Wildcard CSP Rules, Auto-Creates Script Sources and Blocks SPFx Deployments

[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

Windows

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 > Trusted script sources

Describe the bug / error

SharePoint Online automatically adds new entries to the Trusted Script Sources list when deploying updated SharePoint Framework (SPFx) packages, even though a generic wildcard rule already exists for the same CDN domain.

In my tenant, I have intentionally configured broad CSP rules such as:

• https://cdn.{my-company}.net/*
• https://cdn.{my-company}.net/

These entries should allow all JavaScript assets hosted anywhere under this CDN domain.
However, each time a new SPFx package version is deployed, SharePoint automatically creates a new CSP entry corresponding to the specific asset folder used in that package (e.g., versioned folders like /releases/2025.12.3.64390/).

This behavior causes the number of CSP entries to grow indefinitely, eventually hitting the 300-entry limit for the Trusted Script Sources page. As we deploy updates several times a week across multiple customers, this limit will be reached very quickly.

Therefore, the automatic creation of entries appears to ignore existing wildcard CSP rules, which is not the expected behavior and creates a scalability issue for ongoing SPFx deployments.

Critical issue:
Once this limit is reached, SharePoint Online blocks the deployment of any new SPFx packages or package updates in the App Catalog. This means we are no longer able to deploy bug fixes, enhancements, or new versions of our solutions.

Since our solutions are deployed across several hundred customers, this issue has a very large operational impact and prevents us from maintaining our products.

Steps to reproduce

1. In SharePoint Admin Center → Content Security Policy, add a wildcard CSP rule for a CDN, e.g.:
   • https://cdn.{my-company}.net/*
   • or https://cdn.{my-company}.net/
2. Deploy an SPFx package that stores its assets in a versioned folder on this CDN.
3. Install and deploy the solution in the App Catalog.
4. Check the Trusted Script Sources list.
5. Notice that SharePoint automatically adds a new entry for the exact versioned CDN path, even though it matches the existing wildcard rule.
6. Repeat deployments several times with a new versioned folder until the 300-entry limit is reached.
7. Attempt to deploy a new SPFx package or update.
8. Observe that deployment fails, because no more CSP entries can be added.

Expected behavior

SharePoint Online should:

• Respect existing wildcard CSP rules.
• Avoid creating redundant Trusted Script Source entries when a URL is already covered by a wildcard domain.
• Prevent the CSP list from growing unnecessarily and hitting the 300-entry limit.

If wildcard entries were respected, the number of CSP entries would remain stable, and we would be able to continue deploying updates without interruption.

This behavior is essential for environments with frequent SPFx deployments, especially when supporting hundreds of customer tenants.

[Ashlesha-MSFT]

Hello @jbolliet-mozzaik365,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
If you don’t receive a reply within two working days, please use this escalation form to escalate.

[Ashlesha-MSFT]

@jbolliet-mozzaik365,
Based on current SharePoint Online behavior and Microsoft’s CSP documentation, this scenario is best classified as a scalability limitation, not a bug.

There is a hard limit of 300 Trusted Script Sources. If more entries are needed, the recommendation is to use wildcards to consolidate them.

wildcards are supported, but only if they’re not too permissive.
CSP expressions that are too permissive such as *, *.domain, ‘unsafe-inline’, ‘wasm-unsafe-eval’ and ‘strict-dynamic’ are not allowed.

(Ref: https://blog-en.topedia.com/2025/09/why-sharepoint-admins-should-not-ignore-content-security-policy-violations/
)

However, SPFx deployments using versioned CDN paths still generate explicit entries for each version, even when a wildcard should theoretically cover them. This is by design for security reasons, but it creates a scalability limitation, especially in environments with frequent SPFx deployments.

Please submit this as a CSP scalability feature request so it can be reviewed by Microsoft engineering:
https://feedbackportal.microsoft.com/feedback/forum/06735c62-321c-ec11-b6e7-0022481f8472

[jbolliet-mozzaik365]

Thank you for your response.

I still have a question regarding how the wildcard works.
If SharePoint automatically detects the sources from a *.sppkg package and then adds them to the Trusted Sources list even if that url sources match the wildcard, what is the actual purpose of using a wildcard in the CSP configuration?

In other words:

• A wildcard is supposed to allow trusting a broader set of domains without having to declare each one individually.
• But if SharePoint replaces or supplements this wildcard by explicitly adding all detected child sources, then the wildcard seems to lose its intended usefulness and I have to remove manually the explicit sources again and again and again.

Could you clarify the logic behind this behavior?
And more importantly, what is Microsoft’s recommended approach when one genuinely wants to rely on a wildcard without SharePoint explicitly expanding it into individual sources?

Thank you in advance for the clarification.

[Ashlesha-MSFT]

@jbolliet-mozzaik365,
Thank you for the detailed question. After reviewing Microsoft's official CSP documentation, I need to be transparent: the current documentation does not fully address the wildcard behavior you're experiencing.

I'm escalating this to the SharePoint engineering team for clarification on raised questions.

[jansenbe]

@jbolliet-mozzaik365 : what you experience is indeed how things work today and I understand this model has limitations if you deploy a lot with new CDN urls each time. For now you can maybe script the removal of the FQDN entries as a workaround. We've support in SPO Management Shell. I'll check with engineering to see what we can do to improve this.