GTconsult - Blog #March 2026GTconsult - Blog #March 2026https://www.gtconsult.com/blogs/tag/march-2026Wed, 01 Apr 2026 00:17:39 -0700http://zoho.com/sites/<![CDATA[SharePoint CSP Enforcement Is Live — Here's What to Do If Your Scripts Are Broken]]>https://www.gtconsult.com/blogs/post/sharepoint-csp-enforcement-is-live-—-here-s-what-to-do-if-your-scripts-are-brokenSharePoint CSP enforcement broke your scripts? Learn how to diagnose CSP violations, fix inline JavaScript, and register trusted sources in SharePoint Online after the 1 March 2026 deadline.]]>

Microsoft flipped the switch on March 1. If your web parts or custom solutions are suddenly misbehaving, Content Security Policy enforcement is likely the culprit. Here's how to diagnose and fix it.

On 1 March 2026, Microsoft moved SharePoint Online's Content Security Policy (CSP) from report-only mode into full enforcement. That means non-compliant scripts are no longer just being logged, they're being blocked. If something in your environment stopped working around that date, there's a good chance CSP is the reason.

This post walks you through how to confirm CSP is the issue, understand what's being blocked and why, and fix it, without breaking anything else in the process.

Step 1: Confirm CSP Is the Culprit

Before diving into fixes, verify that CSP enforcement is actually what's blocking your scripts. The fastest way is through the browser console.

  1. Open the affected SharePoint page in your browser.
  2. Press  F12  to open Developer Tools and navigate to the Console tab.
  3. Look for errors beginning with  Refused to execute script  or containing Content-Security-Policy .
  4. Alternatively, append  ?csp=enforce  to the page URL to trigger enforcement mode explicitly and surface violations immediately.

If you're seeing CSP violation errors, you're in the right place. If not, the issue may be something else. Check network errors or JavaScript exceptions separately.

Step 2: Identify What's Being Blocked

CSP violations in SharePoint Online generally fall into two categories: inline scripts and untrusted external sources.

Inline Scripts

Any JavaScript written directly into a page, web part, or solution using  innerHTML  ,  document.write()  , or script tags without a proper source reference will be blocked. Microsoft has confirmed that  unsafe-inline  is not permitted and that nonce values will not be exposed, so there is no workaround here. These scripts must be refactored.


Untrusted External Sources

Scripts loaded from external URLs (CDNs, third-party services, custom hosted libraries) that haven't been added to your SharePoint tenant's Trusted Script Sources list will also be blocked. Note that standard SPFx bundles deployed via  cdnBasePath  or declared in  externals  in your config are auto-trusted, it's dynamic loading via  SPComponentLoader.loadScript()  or ad-hoc external references that need manual registration.

TENANT-WIDE AUDIT

Go to Microsoft Purview and search for "Violated Content Security Policy" in the audit log. This gives you a full picture of which pages and scripts have triggered violations across your entire tenant, not just the one page you're looking at.


Step 3: Fix Inline Scripts

Inline scripts need to be moved into external  .js  files and hosted in a trusted location. The typical path for SPFx solutions:

  1. Extract the inline JavaScript into a standalone  .js  file.
  2. Deploy the file to a trusted location (e.g., SharePoint document library, Azure Blob Storage, your CDN).
  3. Reference it as an external module within your SPFx solution rather than injecting it inline.
  4. Register the script source as a Trusted Script Source (see Step 4).

For scripts embedded directly in classic-style page layouts or content editor web parts, the same logic applies, extract, host externally, reference externally.

Step 4: Register Trusted Script Sources

For any external URL your solutions load scripts from, you need to add that domain to SharePoint's Trusted Script Sources list. This is done in the SharePoint Admin Center.

Go to SharePoint Admin Center → Advanced → Trusted Script Sources (or use PowerShell).

Add the full domain or path of the external script source. Wildcards are limited, subdomains must be registered individually.

Note the 300 entry limit across your tenant. Audit carefully before adding everything.

Changes can take up to 24 hours to propagate across your tenant.

Via PowerShell:


Add-SPOTenantCdnOrigin -CdnType Private -OriginUrl "https://yourdomain.com/scripts"

Step 5: Coordinate With Third-Party Vendors

If your SharePoint environment includes solutions from third-party vendors, analytics tools, chatbots, form builders, or similar, those vendors may need to update their products to be CSP-compliant. Reach out to them with the specific violation URLs from your Purview audit and ask for a compliance timeline.

In the meantime, you can temporarily register their script sources as trusted, but the long-term fix needs to come from their end if their solutions use inline scripting patterns.

If You're Still on the 90-Day Delay

Some tenants enabled the 90-day enforcement delay using  Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true  before 1 March. If that's you, your enforcement date is 1 June 2026, and it will arrive faster than you think. Use this guide now while you still have the buffer.

FURTHER READING

Still on the 90-Day CSP Delay? Your 1 June Deadline Is Coming

Support for CSP in SharePoint Online, Microsoft Learn

SharePoint Online CSP: Enforcement Dates and Guidance, Microsoft Tech Community


Still dealing with broken scripts after CSP enforcement?

Not sure where to start with CSP?

Chat to us and let's help you navigate this change.

Book a Free Consultation with Our Technical Account Manager, Trevin
]]>Mon, 30 Mar 2026 16:25:43 +0000