GTconsult - Blog #Script SourcesGTconsult - Blog #Script Sourceshttps://www.gtconsult.com/blogs/tag/script-sourcesTue, 31 Mar 2026 12:12:27 -0700http://zoho.com/sites/<![CDATA[SharePoint Online CSP Enforcement: What Admins Need to Do Before March 1, 2026]]>https://www.gtconsult.com/blogs/post/sharepoint-online-csp-enforcement-what-admins-need-to-do-before-march-1-2026Microsoft is enforcing CSP in SharePoint Online on March 1, 2026. Non-compliant scripts will be blocked. Here's what's changing, what's at risk, and how to prepare your environment before enforcement goes live.]]>

Microsoft is rolling out Content Security Policy (CSP) enforcement for all SharePoint Online tenants on March 1, 2026. If you manage a SharePoint environment with custom scripts, SPFx solutions, or third-party integrations, this change could break things — and the clock is ticking.

Here's what's changing, what's at risk, and exactly how to prepare.

What Is CSP and Why Does It Matter?

Content Security Policy is a browser-level security standard that controls which scripts a page is allowed to load and execute. It's one of the most effective defenses against cross-site scripting (XSS), clickjacking, and code injection attacks.


Until now, SharePoint Online has been running CSP in report-only mode — logging violations without actually blocking anything. That changes on 1 March when enforcement goes live. After that date, any script that doesn't comply with the CSP rules will be blocked by the browser, potentially breaking custom web parts, third-party tools, and SPFx solutions.

Key Dates

  • Now through 28 February, 2026 — Report-only mode. Violations are logged but scripts still run.
  • March 1, 2026 — CSP enforcement begins. Non-compliant scripts are blocked.
  • June 1, 2026 — Extended deadline if you opt in to the 90-day delay via PowerShell.

What Will Be Blocked?

Not everything is affected. Here's a breakdown of the four common script patterns and their CSP impact:

1. SPFx bundles hosted in ClientSideAssets (default pattern)
No action needed. These are trusted automatically.

2. External CDN bundles via cdnBasePath
No action needed. SharePoint auto-adds the CDN domain to Trusted Script Sources when the app is installed.

3. External libraries loaded via the externals config
No action needed. The CDN domain is auto-trusted.

4. Dynamic script loading via SPComponentLoader.loadScript()
Action required. You must manually add the script source to the Trusted Script Sources list in SharePoint Admin Center.

5. Inline scripts (JavaScript in HTML, event handlers, innerHTML, document.write())
These will be blocked outright. There is no nonce workaround — Microsoft has confirmed they will not expose nonce values. You must refactor inline scripts into external files and register them as trusted sources.

How to Audit Your Environment

Step 1: Check the Browser Console

Open any SharePoint page that uses custom solutions, press F12 to open Dev Tools, and look for CSP violation messages in the Console tab. You'll see entries like:

  • "Loading the script '<url>' violates the following..."
  • "Executing inline script violates the following Content Security Policy directive..."


Step 2: Use Microsoft Purview

For a tenant-wide view, go to Microsoft Purview (purview.microsoft.com) and create an audit report filtering for the activity "Violated Content Security Policy." This gives you a comprehensive list of every page and script generating violations across your environment.


Step 3: Review the Directives

Pay attention to both Directive 12 (script-src) and Directive 13 (style-src) violations. Both are relevant — Directive 13 applies to inline code constructs that will also be blocked under enforcement.

How to Fix It

Add Trusted Script Sources

Go to SharePoint Admin Center → Advanced → Script sources and add any external domains your solutions depend on. A few things to note:

  • You can add up to 300 entries.
  • Overly broad wildcards like*or*.domainare not allowed.
  • Use targeted wildcards to consolidate where possible.
  • If a script loads from a CDN, you need to trust that specific CDN domain.

Refactor Inline Scripts

This is the big one. Any JavaScript embedded directly in HTML, event handlers, or injected viainnerHTMLordocument.write() must be moved into external.jsfiles hosted at a trusted location. There's no shortcut here —unsafe-inlineis not permitted, and Microsoft will not provide nonce values.


Validate Auto-Trusted Sources

If you usecdnBasePathwithout a trailing slash, the auto-generated Trusted Script Sources entry may not match correctly. Double-check these entries manually after deploying your solutions.

Buying More Time

If your team isn't ready by 1 March, you can delay enforcement by 90 days using the SharePoint Online Management Shell:

This pushes enforcement to June 1, 2026. It's a one-time delay — use it wisely and don't treat it as a permanent fix.

What Abouteval()?

Good news on this front: Microsoft's CSP implementation includesunsafe-evalin thescript-srcdirective, soeval()calls in your scripts will continue to work. This was confirmed by the SharePoint team in the community discussion.

Communicate With Your Users

Once enforcement begins, end users may see broken functionality or warning messages on pages that rely on non-compliant scripts. Get ahead of this with proactive communication:

  • Explain that this is a security improvement, not a system failure.
  • Provide a clear path for users to report issues.
  • Coordinate with any third-party vendors whose solutions run in your SharePoint environment.

Communicate With Your Users

Once enforcement begins, end users may see broken functionality or warning messages on pages that rely on non-compliant scripts. 


Get ahead of this with proactive communication:


  • ​Explain that this is a security improvement, not a system failure.
    • Provide a clear path for users to report issues.
    • Coordinate with any third-party vendors whose solutions run in your SharePoint environment.


    Bottom Line

    CSP enforcement is a welcome security improvement, but it requires hands-on preparation. The report-only window closes on February 28. Use the time you have to audit violations in Purview, fix inline scripts, register trusted sources, and communicate the change to your users. If you need more time, enable the 90-day delay — but start the work now.

    Further reading:

    ]]>    Wed, 18 Feb 2026 13:04:00 +0000