Trusted Script Enforcement in SharePoint Online: What’s Changing and How to Prepare with SPFx

Recent Posts

Microsoft is aligning SharePoint Online with modern web security standards by enforcing CSP, ensuring scripts can be loaded only from explicitly trusted sources, reducing exposure to risks introduced by inline scripts or unknown external CDNs. According to official Microsoft documentation, any script that does not match the CSP trusted sources list will be blocked once enforcement begins.

This move significantly strengthens overall tenant security, while also standardizing how developers should package and load scripts.

How SharePoint Online Will Be Affected

1. Script Blocking Begins on March 1, 2026

Microsoft will begin enforcing CSP on this date, blocking any script loaded from a non‑trusted location, and blocking all inline scripts, regardless of source.

If needed, organizations can delay enforcement by 90 days, until June 1, 2026, using:

Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true

2. Existing Customizations May Break

Many classic SharePoint customizations rely on:

• Inline JavaScript in pages or scripts embedded in web parts
• External scripts loaded directly from CDNs
• Unregistered script locations

Once CSP is enforced, these patterns will cause breakages. Microsoft’s SharePoint team confirms that any SPFx solution loading scripts from non‑allowed sources will stop functioning as designed.

3. Trusted Script Sources Now Managed in the Admin Center

SharePoint Online now includes a Trusted Script Sources area in the Admin Center (Advanced → Script sources), where administrators can add approved domains. These sources are automatically treated as CSP‑compliant.

When an SPFx solution is packaged correctly, SharePoint automatically adds its script CDN to this trusted source list.

4. Inline Scripts Will No Longer Be Allowed

Inline script execution will violate CSP and be blocked. All inline logic must be moved into JavaScript files and referenced via trusted sources.

Why These Updates Matter

Microsoft’s enforcement makes SharePoint Online environments more secure by:

• Eliminating risky inline scripting
• Ensuring only trusted sources can execute code
• Minimizing opportunities for XSS vulnerabilities
• Establishing consistent governance over external script dependencies

This is a significant modernization for SharePoint’s security posture and long overdue given today’s threat landscape.

The Developer Path Forward: Using SPFx for Secure and Productive Solutions

Developers who rely on classic script injection, Script Editor Web Parts, or inline scripts need to transition to supported development models. The best‑fit model is the SharePoint Framework (SPFx).

Here’s how SPFx helps and what patterns developers should adopt.

How SPFx Improves Security

1. Scripts Are Packaged in .sppkg Files

By default, SPFx bundles JavaScript inside the package, which is deployed to the ClientSideAssets library, a trusted location under CSP. As Microsoft notes, these scripts will continue working without changes.

2. External CDNs Can Still Be Used—Securely

If developers host SPFx bundles on a CDN, SharePoint automatically adds the CDN to Trusted Script Sources during deployment, provided it is referenced correctly in cdnBasePath.

3. Eliminates Inline Scripts

SPFx requires all code to be modular and externalized, which aligns perfectly with CSP’s restrictions.

How SPFx Improves Productivity

Beyond security, SPFx offers significant productivity advantages:

• Reusable components that can be deployed tenant‑wide
• Modern toolchains (React, TypeScript, webpack)
• Enterprise‑ready packaging and lifecycle management
• Full integration with Microsoft 365, including Teams, Viva, and Graph API

This dramatically reduces maintenance overhead compared to one‑off custom scripts.

Recommended Migration Strategy

1. Audit Existing Customizations

Open the browser console and look for CSP warnings (currently in report‑only mode). Microsoft recommends using these warnings to identify scripts that will be blocked.

2. Move Inline Scripts to External Files

CSP will block inline JavaScript completely. Consolidate all inline logic into external JS files.

3. Convert Classic Script Customizations to SPFx Web Parts or Extensions

This includes:

• Script Editor Web Parts
• Custom JS injection
• User Custom Actions with inline code

4. Adopt SPFx Packaging Best Practices

Microsoft provides guidance to ensure script sources are automatically included as trusted:

• Ensure CDN URLs are correctly placed in internalModuleBaseUrls in SPFx manifests.

5. Use the Trusted Script Sources List for External Library CDNs

If using external libraries through SPFx externals, add those CDNs to Trusted Script Sources.

Conclusion

The upcoming enforcement of Trusted Script Enforcement / CSP represents a major shift—but one that significantly enhances the security and integrity of SharePoint Online. While some legacy customizations will break, Microsoft’s roadmap is clear: move to SharePoint Framework (SPFx) as the modern, secure, and fully supported model for extending SharePoint.

Developers who embrace SPFx will gain:

• Strong security alignment with CSP
• Automatic trusted script management
• A future‑proof development platform
• Improved maintainability and enterprise scalability

Now is the time to audit your environment, migrate away from risky patterns, and adopt SPFx – all before March 1, 2026.