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.
- Open the affected SharePoint page in your browser.
- Press F12 to open Developer Tools and navigate to the Console tab.
- Look for errors beginning with Refused to execute script or containing Content-Security-Policy .
- 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
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:
- Extract the inline JavaScript into a standalone .js file.
- Deploy the file to a trusted location (e.g., SharePoint document library, Azure Blob Storage, your CDN).
- Reference it as an external module within your SPFx solution rather than injecting it inline.
- 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.