SharePoint Online Content Security Policy Enforcement

Many organizations unknowingly expose their SharePoint environments to security risks through custom scripts or third-party solutions. To address this, Microsoft is rolling out CSP (Content Security Policy) enforcement for all SharePoint Online tenants. This update is aimed at strengthening protection against malicious scripts that could run within SharePoint pages, embeds, or custom solutions.

If your organization relies on custom scripts, or third-party solutions, now is the perfect time to review and address any potential issues before CSP enforcement begins. Let’s take a closer look at what CSP is and the detailed enforcement timeline.

Content Security Policy is a browser-level security standard that limits which scripts, styles, images, and other resources a webpage is allowed to load. If a resource isn’t explicitly trusted, the browser blocks it. It helps guard against common web attacks like cross-site scripting (XSS), clickjacking, and other code injection attempts.

With Microsoft introducing full CSP enforcement in SharePoint Online, every script a page tries to load will now be checked against strict trust rules. This is a significant change that reshapes how customizations, SPFx solutions, and third-party components will behave across SharePoint sites.

Earlier, SharePoint Online did not validate the origin of scripts. Any script referenced on a page or inside a solution was executed automatically. This allowed useful customization but also opened the door for untrusted or risky scripts to run.

With CSP active, things work differently. Now every script request goes through a quick verification:

• If the script’s location is listed in the CSP rules, the browser loads it normally.
• If the script’s location isn’t permitted, the browser won’t load it and logs an error in the console.

This is especially important for custom solutions built using SharePoint Framework (SPFx), which often rely on external libraries or dynamic script loading.

Now – Feb 28, 2026: Content Security Policy in Report-Only Mode

During this period, CSP is active but not enforcing any restrictions. That means no scripts will be blocked yet. Instead, any violations are simply logged in the browser console. This is your golden opportunity to audit your SharePoint sites, identify scripts that might cause issues, and make necessary fixes without disrupting users.

March 1, 2026: CSP Enforcement Begins

Starting March 1, CSP goes from “report-only” to full enforcement. Any scripts or resources that don’t comply with the CSP rules will be blocked automatically.

Postpone Enforcement by 90 Days

If you need extra time to ensure all custom scripts and third-party solutions are compliant, SharePoint provides a 90-day postponement option. By running a simple PowerShell command, enforcement can be delayed until June 1, 2026, giving you extra breathing room to fix scripts safely.

Here’s how CSP enforcement affects different ways you load scripts in SPFx.

✅ Standard SPFx Packaging

If your SPFx bundles are packaged normally inside the .sppkg file and stored in ClientSideAssets, you’re already compliant. SharePoint automatically trusts this location.

✅ Hosting SPFx Bundles on an External CDN

If you’re using cdnBasePath in your write-manifests.json file to host your SPFx bundles on a CDN, SharePoint will automatically trust that CDN once the app is installed. This means CSP won’t block it, and you don’t need to make any manual changes.

✅ Using External Libraries from a CDN

If your solution loads libraries like jQuery or Chart.js directly from a CDN instead of bundling them, SharePoint will automatically trust those CDN domains. This setup works with CSP.

❌ Dynamically Loading Scripts with SPComponentLoader

If your code uses SPComponentLoader.loadScript() to load scripts while the app is running, SharePoint will not trust that script source by itself. You must manually add the script’s domain in the SharePoint Admin Center under Advanced → Script Sources. You only need to do this if the domain isn’t trusted already.

❌ Inline Scripts (Not Allowed Anymore)

Inline JavaScript, like scripts inside HTML tags, onclick attributes, or script tags inserted via innerHTML, will be completely blocked by Content Security Policy. To fix this, you must remove all inline JavaScript and move it into proper external script files or modules. Also make sure any external domains you rely on are added to the trusted script sources list.

Use this checklist to validate your scripts and avoid unexpected blocks once CSP becomes mandatory.

• Audit content security policy violations
• Configure trusted script sources
• Remove inline scripts and modernize code
• Test SPFx solutions against CSP enforcement

Start by opening your SPFx solution in the browser and keeping the Dev Tools console (F12) visible. As you load the app, watch for any CSP violations in the browser’s console, like:

• “Loading the script <url> violates the following…”
• “Executing inline script violates the Content Security Policy…”

These messages are your first clue that something in your solution won’t pass once enforcement goes live.

CSP violations are also captured in Microsoft Purview for audit and compliance review. You can generate a report to see every violation logged across your tenant.

Steps to View CSP Violations in Microsoft Purview:

1. Open Microsoft Purview and go to the Audit section.
2. In the Activities – friendly names search bar, look for the activity “Violated Content Security Policy”.
3. Run the query to view all logged CSP violations across your environment.
4. Export the results if needed for remediation, tracking, or reporting.

To prevent external CDN or third-party scripts from being blocked, update your approved domains list in the SharePoint admin center.

Steps to configure trusted script sources in SharePoint admin center:

1. Sign in to the SharePoint admin center.
2. Navigate to Advanced –> Script Sources and click on Add source.
3. Enter the CDN or external domain hosting your SPFx bundles, scripts, or resources and click Add.

This ensures SharePoint recognizes these domains as trusted and allows your scripts to load smoothly during CSP enforcement.

CSP enforcement means SharePoint will no longer allow inline JavaScript. Audit your sites for inline <script> tags, embedded logic, and event attributes. Move these into properly referenced external files and modernize the codebase.

You can begin testing your SPFx solutions against SharePoint Online’s Content Security Policy before the official enforcement date. Add csp=enforce to your page URL to see how your SPFx scripts behave under CSP rules. To test in report-only mode without blocking scripts, use csp=report.

Apart from the above, you can also use a third-party Content Security Policy Checker to scan blocked or non-compliant script sources across your tenant.

To temporarily postpone CSP enforcement for your tenant, run the following command. Firstly, connect to the SharePoint Online Management Shell module.

Note: This option becomes available after the November 2025 SPO release.

For developers, CSP enforcement is an opportunity to clean up older patterns and adopt more modern, secure practices. By handling violations ahead of time, you’ll be building solutions that align with Microsoft’s long-term security roadmap! If you have any queries, feel free to reach us through the comment section.