SharePoint Online Content Security Policy (CSP): Enforcement Dates and Guidance

Content Security Policy (CSP) is a critical browser security feature designed to protect web applications from threats like cross-site scripting (XSS), clickjacking, and other code injection attacks. CSP allows site owners to specify which resources (scripts, styles, images, etc.) a page can load, reducing the risk of malicious code execution.

SharePoint Online is rolling out CSP enforcement for all tenants starting March 1, 2026. Until then, CSP is in "report-only" mode - no scripts are blocked yet, but violations are logged. This change will have a direct impact on your SharePoint Framework (SPFx) solutions, especially those that load scripts from external sources or use inline scripts.

Key Dates:

• Now–Feb 29, 2026: CSP in report-only mode (no blocking, only logging)
• March 1, 2026: CSP enforcement begins (blocking non-compliant scripts)
• Optional: Delay enforcement by 90 days (until June 1, 2026) using PowerShell

How CSP Works in SharePoint Online

When a page loads, the browser checks every script request against the CSP rules set by SharePoint Online. If a script’s source is not explicitly allowed, the browser blocks it and logs a violation. This applies to both external scripts and inline scripts (JavaScript embedded directly in HTML or event handlers).

Learn more: Content Security Policy (CSP) - Mozilla.

Impact on SPFx Solutions

Default Behavior

By default, SPFx solutions package their JavaScript bundles inside the *.sppkg file. When deployed, these assets are hosted in the site’s ClientSideAssets library, which is trusted by the default SharePoint Online CSP configuration. If you follow this pattern, your solution will continue to work without changes.

Common Script Loading Patterns

However, some developers use alternative patterns for script loading and hosting. Here’s how CSP enforcement will affect each:

1. External CDN for SPFx Bundles
   • Pattern: JavaScript bundles are hosted on a vendor-managed CDN, referenced via cdnBasePath in write-manifests.json.
   • CSP Impact: SharePoint Online will automatically add the CDN domain to the Trusted Script Sources list when the app is installed. No manual action is needed if you follow the documented packaging process.

2. External Libraries via CDN
   • Pattern: Libraries are excluded from the bundle and loaded at runtime from a CDN, configured via the externals property in config.json.
   • CSP Impact: The CDN domain is added to Trusted Script Sources automatically. Again, no manual action is needed if you follow the guidance.

3. Dynamic Script Loading (SPComponentLoader)
   • Pattern: Scripts are loaded dynamically in code using SPComponentLoader.loadScript().
   • CSP Impact: If the script source is not already trusted, you must manually add it to the Trusted Script Sources list in the SharePoint Admin Center.

4. Inline Scripts
   • Pattern: JavaScript is embedded directly in HTML, event handlers, or injected via innerHTML, document.write(), etc.
   • CSP Impact: Inline scripts will be blocked. You must refactor your solution to move all inline scripts into external files and register those files as trusted sources.

Preparing for CSP Enforcement

1. Audit Your Solutions
   • Open your SPFx solutions in the browser with Dev Tools (F12) Console open.
   • Look for CSP violation messages, such as:
     • Loading the script '<url>' violates the following...
     • Executing inline script violates the following Content Security Policy directive...

Example browser console entries when the custom scripts are not properly listed in the trusted scripts area in the tenant.

• • Violations are also logged to Microsoft Purview for audit and compliance tracking. Create a report searching for Activity - friendly names value Violated Content Security Policy to get a list of CSP violations.

Example query settings with the Violated Content Security Policy activity selected.

2. Update Trusted Script Sources
   • Go to SharePoint Admin Center > Advanced > Script sources.
   • Add any required external domains as trusted sources.
   • Note: Overly permissive wildcard expressions (e.g., *, *.domain) are not allowed. You can add up to 300 entries; use wildcards to consolidate where possible.

3. Refactor Inline Scripts
   • Move all inline scripts into external files.
   • Register those files as trusted sources.
   • Update your SPFx solutions and redeploy.

4. Delay Enforcement (If Needed)

If you need more time, you can delay CSP enforcement for your tenant by 90 days (until June 1, 2026) using the SPO Management Shell:

Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true

This option will be available in the SPO Management Shell starting from the end of November 2025 release.

Final Thoughts and Resources

CSP enforcement is a major step forward for SharePoint Online security, but it requires action from developers. Start auditing your solutions now, refactor any inline scripts, and ensure all external script sources are registered as trusted. This will help avoid disruptions when enforcement begins.

Further reading and resources

• Support for Content Security Policy (CSP) in SharePoint Online - Microsoft Learn